Re: i93: Repeating Single-value headers

On Sat, Jan 05, 2008 at 11:32:43PM +0100, Henrik Nordstrom wrote:
> On ons, 2008-01-02 at 18:44 -0800, David Morris wrote:
> 
> > If we have a specific set of suggestions for certain errors, it might be
> > better to produce a BCP document as a companion rather than encumbering
> > the revised spec with details really in the domain of the implementor.
> 
> Yes, with the exception of Content-Length when used as message delimiter
> which has a direct security impact on the protocol itself, and not only
> it's use..


How does a "security impact" looks like on something not used?


> What I have in mind regarding Content-Length is to add a condition
> (probably in "Message Length") that when a recipient sees a messages
> with conflicting repeated content-length headers the recipient SHOULD
> (MUST?) either reject the invalid message as invalid, ignore the
> Content-Length or close the connection after processing the message.

> Randomly picking one of the values in a best effort to try to understand
> the message while keeping the connection open is not acceptable for a
> conformant implementation.


Even you see different good choices, and I see even more depending on 
the situation. - But I don't see how to mix "randomly picking" and 
"understand the message".

You want to mandate reactions to invalid messages involving wrong 
"Content-Length" header. - Why? - To void possible security bugs in 
firewalls? There are many ways to screw up a firewall, no need to make 
one of these ways against the HTTP spec.

Invalid input needs to be handled accordingly, Content-Length is no 
exception, but not overly special, either.

I see only space for the inclusion of some implementation advise like:

"Special care must be taken on invalid input involving wrong (multiple) 
Content-Length headers. Implementors could choose to always reject such 
messages. "


Regards,
Robert

Received on Sunday, 6 January 2008 16:08:33 UTC