Daniel Stenberg wrote:
>
> Hi
>
> A friendly soul named Antti Valtokari added a suggestion in the curl feedback
> forum, that we should add support for the letter '=' in form field names:
>
> http://curl.haxx.se/feedback/display.cgi?id=10002820566576&support=yes
>
> Now I'm asking you for a different approach than the one suggested by Antti.
> His way of introducing \ as an escape letter in the form field string doesn't
> really seem fitting. It modifies the present treatment of \ (as it would
> require that a single \ is written \\ in the future) and the same letter is
> already used as a common shell escape letter, which might make it confusing
> to users that at times you would be forced to use very many backslashes.

I didn't read the RFC yet, but I assume that if you really want a form
field name with an illegal character in it (like '='), you must
url-escape it before presenting it to the HTTP server.

The issue, then, is whether curl is responsible for URL escaping form
field names and contents for the user, and whether it should do both
name and value, or just one or neither...

> The best way might be to separate the name and the contents with two
> different options (--form-name and --form-value perhaps). This would of
> course break compatibility with how -F works today, but would prevent us from
> having to introduce an escaping mechanism.
>
> A different option would be to treat the entire string, or perhaps only the
> part to the left of the '=' letter, as an URL encoded string that is decoded
> before passed on. Thus Antti's example could've been written
> fieldname:TYPE%3d123412=value (with %3d instead of '=').
>
> So, we have a bunch of different alternatives:
>
> 1) Antti's \-suggestion
> 2) introduce two separate options for the single -F of today
> 3a) URL decode the both sides of the = letter in the -F string
> 3b) URL decode only the left side of the = letter in the -F string
> 4) A totally different approach
> 5) Do nothing, = letters in form field names are illegal

I'm not sure if 5 is true or not - I suspect its OK to have them
(bizarre, but OK) if you escape them. It's probably going to affect many
buggy libraries that didn't read the RFC but....

For 3/3a, why does curl need to decode the string (on either side of =)
- its only going to re-encode it again before passing it to the server.
Does curl actually split the command line data on the '=' currently, or
simply paste 'name=value' pairs together? (Use the source, Cris.
Lazy...)

I think the issue is simpler - does curl expect user input to be url
encoded or not? The current behaviour is 'not' - curl will do the URL
encoding for the user. You can add a switch
'--clever-user-already-escaped-forms-and-various-other-stuff-dont-do-it-again'
- which allows Anti to do 'TYPE%3d123412=value' and add the new switch,
and have curl pass through exactly what he put, but retain the current
behaviour and be smart enough for more straightforward users...

I don't know whether this propogates into libcurl, or is entirely curls'
problem...

Cris
Received on 2001-09-24