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" <a...@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. >
