Re: patch: url encode, append input
Hi, On Mon, Apr 07, 2008 at 02:26:14PM +0000, corvid wrote:
a_Url_encode_hex_str() needed to accept a Dstr* because it is not illegal to use url encoding on a file. Maybe a situation that'll never happen, but then again, it's easy to leave off enctype.
In that case the behaviour is not specified. i.e. (from http://www.ietf.org/rfc/rfc1867.txt): 5.8 File transfer with ENCTYPE=x-www-form-urlencoded If a form contains <INPUT TYPE=file> elements but does not contain an ENCTYPE in the enclosing <FORM>, the behavior is not specified. It is probably inappropriate to attempt to URN-encode large quantities of data to servers that don't expect it.
(However, Firefox -- as if it's any authority on anything, but still -- doesn't send file contents for URL encoded forms. It just sends the filename.)
Probably is not a bad idea to follow this lead or investigate a bit further on what IE, Safari or Opera do, and then decide. At least, I'd feel more comfortable with a file-size limit for both GET&POST, thus avoiding Dillo to exit because it can't allocate enough memory for sending a huge file.
Html_append_input() becomes a few functions (I'd never felt good about sending a boundary arg for url encoding anyway).
OK. -- Cheers Jorge.-
Jorge wrote:
On Mon, Apr 07, 2008 at 02:26:14PM +0000, corvid wrote:
a_Url_encode_hex_str() needed to accept a Dstr* because it is not illegal to use url encoding on a file. Maybe a situation that'll never happen, but then again, it's easy to leave off enctype.
In that case the behaviour is not specified.
i.e. (from http://www.ietf.org/rfc/rfc1867.txt):
5.8 File transfer with ENCTYPE=x-www-form-urlencoded
If a form contains <INPUT TYPE=file> elements but does not contain an ENCTYPE in the enclosing <FORM>, the behavior is not specified. It is probably inappropriate to attempt to URN-encode large quantities of data to servers that don't expect it.
(However, Firefox -- as if it's any authority on anything, but still -- doesn't send file contents for URL encoded forms. It just sends the filename.)
Probably is not a bad idea to follow this lead or investigate a bit further on what IE, Safari or Opera do, and then decide.
At least, I'd feel more comfortable with a file-size limit for both GET&POST, thus avoiding Dillo to exit because it can't allocate enough memory for sending a huge file.
Ohh... I thought RFC 1867 was just an old version of RFC 2388 (Returning Values from Forms: multipart/form-data), so I never looked at it. I'd prefer not to send the file at all if we don't have to.
On Tue, Apr 08, 2008 at 09:16:47PM +0000, corvid wrote:
Jorge wrote:
On Mon, Apr 07, 2008 at 02:26:14PM +0000, corvid wrote:
a_Url_encode_hex_str() needed to accept a Dstr* because it is not illegal to use url encoding on a file. Maybe a situation that'll never happen, but then again, it's easy to leave off enctype.
In that case the behaviour is not specified.
i.e. (from http://www.ietf.org/rfc/rfc1867.txt):
5.8 File transfer with ENCTYPE=x-www-form-urlencoded
If a form contains <INPUT TYPE=file> elements but does not contain an ENCTYPE in the enclosing <FORM>, the behavior is not specified. It is probably inappropriate to attempt to URN-encode large quantities of data to servers that don't expect it.
(However, Firefox -- as if it's any authority on anything, but still -- doesn't send file contents for URL encoded forms. It just sends the filename.)
Probably is not a bad idea to follow this lead or investigate a bit further on what IE, Safari or Opera do, and then decide.
At least, I'd feel more comfortable with a file-size limit for both GET&POST, thus avoiding Dillo to exit because it can't allocate enough memory for sending a huge file.
Ohh... I thought RFC 1867 was just an old version of RFC 2388 (Returning Values from Forms: multipart/form-data), so I never looked at it.
Yeah, browsing RFC dependencies is confusing sometimes... Jukka Korpela usually has pretty solid advice: http://www.cs.tut.fi/~jkorpela/forms/file.html#rfc The whole page is insightful, the anchor points to: "The status of RFC 1867"
I'd prefer not to send the file at all if we don't have to.
After reading the document quickly, I'd also prefer not to send the file. Please let me know your thoughts. -- Cheers Jorge.-
participants (2)
-
corvid＠lavabit.com -
jcid＠dillo.org