Re: [ietf-types] The application/www-form-urlencoded format

["Anne van Kesteren" <[e-mail]>]

On Sun, 26 Sep 2010 22:19:40 +0200, Bjoern Hoehrmann <[e-mail]>  
wrote:
> * Anne van Kesteren wrote:
>> I think it is unfortunate it still allows encoding in various ways. So
>> while things could be more readable as you pointed out in the past user
>> agents are still allowed to obscure most everything.
>
> I do think that encoder implementers can make reasonable choices about
> that. If an implementer decides it's best to escape, say, the zero-width
> space character because it's invisible then I see nothing wrong with
> that. If another implementer decides to not escape it, that's fine too.

I suppose. And I guess if we ever decide to implement any of this we could  
make more specific requirements in the forms section of HTML for that  
class of implementors.

After having thought about it some more I am doubting this would be a very  
useful addition though. The benefit over application/x-www-form-urlencoded  
seems marginal. Not high enough to warrant the cost.


>> The bug about + seems to be still be there. Escapes are first decoded  
>> and
>> then + is replaced with U+0020. Also application/x-www-form-urlencoded  
>> is
>> on its way of being standardized as part of HTML5 now.
>
> I don't think there is anything that "HTML5" could standardize about it,
> other than define how form submission using that type should be imple-
> mented in HTML implementations. As for the +, the text refers to the ab-
> stract syntax tree you get when parsing a string using the grammar, so
> an escaped plus sign is no instance of `plus`. I take it that's one of
> the text's rough edges I should smooth out.

I guess. I'm not very good at reading grammar / prose combinations. (I  
thought that after the escape was handled you would have instances of  
plus.)


>> Most other such formats ignore a leading U+FEFF.
>
> I can't think of any format that's always UTF-8 encoded yet allows for
> it, but anyway, treating it as part of a name is simpler than ignoring
> it, I think people are more likely to implement that correctly than if
> I were to require recognizing it.

text/event-stream and text/cache-manifest.


-- 
Anne van Kesteren
http://annevankesteren.nl/