REGRESSION(r50072): Mailman administrative functionality is broken

• Component: New Bugs
• Status: RESOLVED FIXED

[William Siegrist]

Reduced case: http://src.macosforge.org/webkit-post-data-bug-test.php

If you check a box and hit the corresponding submit button, you'll notice the checkbox name "abc%40def" is encoded as "abc%2540def" only when multipart encoding is used.  I would expect the field name to be the same in both cases. Firefox 3.5.5 and Safari 4.0.4 do not encode the name. I can reproduce with nightly r51580.

[Mark Rowe (bdash)]

This regressed in <http://trac.webkit.org/changeset/50072>.  It breaks administrative functionality within the Mailman interface that is used on lists.webkit.org.

[Mark Rowe (bdash)]

Why did we choose to URL encode field names within these headers?  The only thing that RFC 2388, the multipart/form-data specification, has to say about encoding of field names is:

>    Field names originally in non-ASCII character sets may be encoded
>    within the value of the "name" parameter using the standard method
>   described in RFC 2047.

RFC 2047, Message Header Extensions for Non-ASCII Text, appears to discuss the use of quoted-printable encoding.  The cases we are concerned about a clearly not non-ASCII, but this does seem to directly conflict with our decision to URL encode the field names.

[Mark Rowe (bdash)]

<rdar://problem/7443458>

[Alexey Proskuryakov]

Percent escaping was chosen randomly, we can definitely try another encoding form. Encoding the percent sign itself was a poorly thought through last minute change, and it can be just removed from the set of encoded characters for an easy fix.

I did not know about RFC 2388, and I do not know if anyone follows it.

[Alexey Proskuryakov]

Created attachment 44644 [details]
proposed fix

[WebKit Review Bot]

style-queue ran check-webkit-style on attachment 44644 [details] without any errors.

[Mark Rowe (bdash)]

Comment on attachment 44644 [details]
proposed fix

I don’t understand why we *were* using URL encoding for field names.  I don’t understand why we’re now inventing a custom encoding for these fields that looks by all appearances to be URL encoding, and yet cannot be decoded by the other end.

[Alexey Proskuryakov]

Mark has suggested an interesting idea for future consideration - even though RFC 2388 doesn't apply to ASCII characters, we can still use its form of encoding, e.g. =0a. But I don't think we should be changing this now.

[Darin Adler]

Comment on attachment 44644 [details]
proposed fix

This change is clearly good. Maybe we can find a better form of encoding than %-encoding in the future, but this will get rid of the regression without reintroducing the problem we originally were fixing by quoting the name.

r=me

[Alexey Proskuryakov]

Committed <http://trac.webkit.org/changeset/51973>.

[Daniel Bates]

Marking this bug as fixed since it was committed in changeset 51973 <http://trac.webkit.org/changeset/51973>. If this is a mistake then reopen this bug.

[Alexey Proskuryakov]

This was just an oversight - thanks for noticing!