Subject: RE: i93: Repeating Single-value headers

From: "Larry Masinter" <[email-masked]>
Date: Wed, 2 Jan 2008 13:23:37 -0800

> >> I would like us to formulate some guideline beyond the charter when
> >> handling of specific errors is considered in scope of this group's
> >> deliverables (so we would consider adding text pointing out the mis-
> >> behavior, or making recommendations how to handle it). There are
> >> some known cases where errors are common in practise and affect e.g.
> >> efficiency (such as sending malformed If-Modified-Since headers),

In general, defining how one party should respond to invalid values sent by
another party is difficult, because the appropriate behavior is likely to be
context dependent -- is HTTP being used by a browser, a transport for SOAP
protocol messages, or some other application?

I would urge the working group *not* to try to mandate MUST-required
behavior when receiving invalid input -- it turns the "invalid" input into
part of the protocol. It's likely that there are places where, for security
or stability reasons, MUST (or SHOULD) requirements to respond with an error
reply would make sense, but in any case, don't take it on as a specific
charter item.

Larry

---

From: David Morris <[email-masked]>
Date: Wed, 2 Jan 2008 18:44:35 -0800 (PST)

I think the key point to stress is that is is always safe and OK to reject
an invalid request or response. The default behavior, when a reasonable
interpretation isn't identified, SHOULD/MUST be to reject the
request/response. How a server does this is pretty clear. How the client
does it is quite dependant on the nature of the client, but every client
must be prepared to deal with errors.

There may be some cases where the protocol needs to insist on rejection
for security reasons.

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.

Dave Morris

---

From: David Morris <[email-masked]>
Date: Wed, 2 Jan 2008 19:37:57 -0800 (PST)

We have a problem because the current RFC somewhat awkwardly requires that
headers not be repeated unless a list value is allowed ... this correlates
with the permission to fold multiple headers and is neat ...

Except the well known cookie headers must be allowed to repeat and can't
be folded because this syntax requirement wasn't understood by the
designers of the cookie mechanism.

There are other headers such as content-length which by definition would
represent a conflict if the values differed. Not list valued and can't be
folded.

Still other non list valued headers where repeated headers would simply be
a waste of space ... e.g., Date, User-Agent, ...

We could solve the cookie (set-cookie also?) issue by documenting an
exception, or we could reword the requirements such that:
  a. An implementation which follows the current specification remains
     in conformance
  b. Cookie and other unknown repeating headers will be handled safely

What I propose is that we change the repeating headers requirement such
that repeated headers are allowed. Folding is only allowed for repeated
headers defined with LIST values. The order of repeated header values must
be preserved by proxies. Conflicting values in repeated headers is an
error and should be handled as such. Optionally interpret if possible,
otherwise reject the request/response.

In my mind, this means we can ignore cookies, if we choose, because this
revised wording makes it an error to fold an unknown header. It also
allows flexibility with future extensions by allowing the designers to
include repeated headers if that makes sense.

Dave Morris

---

From: Henrik Nordstrom <[email-masked]>
Date: Sat, 05 Jan 2008 23:07:51 +0100

On ons, 2008-01-02 at 19:37 -0800, David Morris wrote:

> revised wording makes it an error to fold an unknown header.

Which is a big change. The current wording always allows combining of
any repeated header, wellknown or unknown extension header never heard
of before, with Cookie being the single (unspecified) exception.

If combining repeated headers renders the message invalid then it was
invalid before the headers was combined. I.e repeated sinngle-valued
header. The only issue (apart from Cookie) is that combining headers may
actually render invalid messages valid by removing the duplicated header
(now a single header with a longer value)

> It also

A repeated header is by definition a list header, and is the default
header format unless known otherwise.

It's better to mention Cookie as an exception, with an informal
reference to the cookie rfc..

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Sat, 05 Jan 2008 23:32:43 +0100

> 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..

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.

Regarding other headers I think it's sufficient to add a reminder that
sending multiple headers of a non-list header renders the message
invalid and MAY be rejected by the recipient, if anything at all needs
to be said about this.

Regards
Henrik

---

From: Robert Siemer <[email-masked]>
Date: Sun, 6 Jan 2008 17:09:22 +0100

> which has a direct security impact on the protocol itself, and not only

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

> 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

---

From: Henrik Nordström <[email-masked]>
Date: Sun, 06 Jan 2008 23:47:42 +0100

sön 2008-01-06 klockan 17:09 +0100 skrev Robert Siemer:

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

I meant application use.

content-length has direct implications on how you parse the protocol and
delimit the messages received in the data stream, the others just impact
how you understand the meaning of the received message.

Regards
Henrik