Processing MIME fields in an HTTP header.

["Alan M. Carroll" <am...@network-geographics.com>]

I am looking at TS-466 (Multiline headers are not preserved) and as far as I can tell this is by design. The field parser in MIME.cc goes to some effort to detect this situation and then strip out the intervening whitespace, including the CR/LF. So something like

Accept: text/html,
        text/xhtml

becomes

Accept: text/html,text/xhtml

Is there any purpose to this? Why would something think this was making an effort to achieve? The multiline format is explicitly allowed by the HTTP spec and the parser code specifically checks for it so it can alter the field value as shown above. Is there any reason to not preserve all the interior whitespace? I presume (haha, foolish me!) that the field value parsers skip over the whitespace.

Re: Processing MIME fields in an HTTP header.

[Leif Hedstrom <zw...@apache.org>]

A wild guess would be that some clients in the bad old days did not handle it right. We should obey the protocol IMO, possibly with having an option to enable this non-compliant behavior per transaction.

-- leif

Ps
Logan airport sucks, that's all... ;)


On Aug 11, 2011, at 2:07 PM, "Alan M. Carroll" <am...@network-geographics.com> wrote:

> I am looking at TS-466 (Multiline headers are not preserved) and as far as I can tell this is by design. The field parser in MIME.cc goes to some effort to detect this situation and then strip out the intervening whitespace, including the CR/LF. So something like
> 
> Accept: text/html,
>        text/xhtml
> 
> becomes
> 
> Accept: text/html,text/xhtml
> 
> Is there any purpose to this? Why would something think this was making an effort to achieve? The multiline format is explicitly allowed by the HTTP spec and the parser code specifically checks for it so it can alter the field value as shown above. Is there any reason to not preserve all the interior whitespace? I presume (haha, foolish me!) that the field value parsers skip over the whitespace.
>