RE: i93: Repeating Single-value headers

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

On Wed, 2 Jan 2008, Larry Masinter wrote:

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

Received on Thursday, 3 January 2008 02:44:49 UTC