Subject: i93: Repeating Single-value headers

From: Mark Nottingham <[email-masked]>
Date: Sun, 23 Dec 2007 22:53:22 +1100

<http://tools.ietf.org/wg/httpbis/trac/ticket/93>

Discussion in Vancouver centred around whether advice about error  
handling in HTTP should be added; Roy Fielding offered to come up with  
exact text for this, but the sense of the room was that we should  
document why HTTP doesn't have a single approach to error handling  
(such as when multiple values are present for a single-valued header),  
because (as I remember the discussion):

   1. There is no one "right" answer; different kinds of clients -- or  
the same client in different situations -- may need to act differently  
upon an error, for most kinds of errors (there may be exceptions), and

   2. Specifying behaviour for handling every conceivable error isn't  
possible, attempting to do so will seriously bloat the specification,  
and will not significantly improve interoperability.

We'll wait for Roy's text to see if there's consensus, but if you have  
a problem with this, speaking up sooner rather than later would be good.

Regarding the other part of the issue ("MAY... if and only if" vs.  
"MUST NOT... unless"), I'd like to call that portion of the issue  
editorial, and let the editors worry it out.

Cheers,

--
Mark Nottingham     http://www.mnot.net/

---

From: Robert Siemer <[email-masked]>
Date: Sun, 23 Dec 2007 14:33:28 +0100

> and will not significantly improve interoperability.

I like that. - I think the most important task of the spec is to make 
clear the spirit that HTTP has, why things are the way they are. With 
that information a considerate implementor can make it's own deliberate 
choice.

Robert

---

From: Julian Reschke <[email-masked]>
Date: Sun, 23 Dec 2007 15:21:06 +0100

> that information a considerate implementor can make it's own deliberate 

+1

It also gives an answer to those who think that error handling for every 
conceivable error case needs to be mandated.

BR, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 25 Dec 2007 22:10:42 +0100

>because (as I remember the discussion):

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),
but I am not sure which of these issues merit raising on 2616bis as
opposed to, say, making a separate non-WG document documenting some
of these issues.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Henrik Nordström <[email-masked]>
Date: Fri, 28 Dec 2007 15:39:21 +0100

> a problem with this, speaking up sooner rather than later would be good.

I agree with the view expressed above, with one exception.
Content-Length deserves an explicit mention due to it's use in parsing
of the protocol itself.

For all other single-valued headers I know about it's sufficient to say
that one SHOULD NOT send more than one value of a header defined as
single-valued, except for proxies & gateways which MAY if the
request/response they received had multiple values for the header in
question.

How recipients deal with multiple values is better left implementation
dependent, with maybe a note to remind implementers that nothing stops
others from sending them malformed data such as multiple values of a
single-valued header, and general MAY rules on how clients respektive
serves should respond when detecting such messages if it matters to the
implementation.

Regards
Henrik

---

From: Henrik Nordström <[email-masked]>
Date: Fri, 28 Dec 2007 15:52:28 +0100

> efficiency (such as sending malformed If-Modified-Since headers),

How to handle malformed If-Modified-Since is already specified. Such
conditionals is simply ignored.

The fact that this leads to degraded performance to clients sending
malformed If-Modified-Since headers giving them the same functionality
as not using conditionals at all is not something the spec needs to go
into. Should be obvious to anyone who analyses the problem with their
implementation.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Dec 2007 17:19:11 +0100

> that one SHOULD NOT send more than one value of a header defined as

Hm. Do you really think it's SHOULD NOT, not MUST NOT?

> ...

BR, Julian

---

From: Henrik Nordström <[email-masked]>
Date: Fri, 28 Dec 2007 18:28:26 +0100

> Hm. Do you really think it's SHOULD NOT, not MUST NOT?

My starting point is SHOULD NOT for anything which does not cause
immediate interoperability breakage.

If diskussions find that violating this is really harmful, not only
slightly confusing to the unsuspecting then upgrade the criteria to MUST
NOT.

It depends a bit on what the wording regarding error handling will be.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Dec 2007 18:36:00 +0100

> It depends a bit on what the wording regarding error handling will be.

Well, if conflicting information in Content-Length headers doesn't cause 
interop problems, what will?

BR, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 28 Dec 2007 20:43:20 +0100

>into. Should be obvious to anyone who analyses the problem with their

The example does not really have much impact on my point, but even if
you are right and implementations are required to ignore the field if
it is malformed, we'd still have an issue, because existing implemen-
tations do not ignore it, and sending malformed headers is so common,
that they are unlikely to change. The specific case I had in mind is
appending garbage to a legal value, like in

  If-Modified-Since: Thu, 22 Jun 2006 18:33:10 GMT GARBAGE
  If-Modified-Since: Thu, 22 Jun 2006 18:33:10 GMT;length=12345
  If-Modified-Since: Thu, 22 Jun 2006 18:33:10 GMT

As an example, Apache 2.2 treats these as identical when deciding if
it should respond with 304 (as it ignores everything after the time).
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Henrik Nordström <[email-masked]>
Date: Fri, 28 Dec 2007 21:43:45 +0100

> interop problems, what will?

Was thinking more on a general rule covering single-valued headers in
general, just to emphasis what the BNF says.

For Content-Length it should be a MUST NOT, but the more interesting
topic to discuss there is how recipients should react when receiving a
message with multiple content-length values.

Regards
Henrik

---

From: Henrik Nordström <[email-masked]>
Date: Sat, 29 Dec 2007 01:56:20 +0100

> it should respond with 304 (as it ignores everything after the time).

Which is fine as there is no doubt what the requestor meant, but not
required by the specs even if roubust and forgiving HTTP-date parsers is
encouraged.

And sorry, my wording was slightly bad before. An invalid
If-Modified-Since date not understood by the recipient should never
result in 304, not ignored. The difference is when combined with
If-None-Match or other conditionals.

Regards
Henrik