response to protocol violations (was: what does "unrecognized header fields" mean?)

I agree that in general, implementing "common tolerant Internet behavior" is
a good thing. However, there are times that for simplicity, security, or
correctness reasons, certain protocol violations must cause error responses
from servers. One that comes to mind is when CTL chars are included in the
message header without first being encoded or inside of a quote string. I've
seen applications (MapQuest might still do this) that attempt to use control
characters in the URL. For security reasons, our proxy refuses to retrieve
requests that violate the protocol in that fashion.

-Rob Polansky

> -----Original Message-----
> From: dmk@research.bell-labs.com [mailto:dmk@research.bell-labs.com]On
> Behalf Of Dave Kristol
> Sent: Tuesday, May 26, 1998 2:41 PM
> To: Ross Patterson
> Cc: http-wg@cuckoo.hpl.hp.com
> Subject: Re: what does "unrecognized header fields" mean?
>
[...snip...]
>
> I don't think it's so crazy for an implementation to treat a malformed
> header as though it were simply missing.  If the header is required for
> proper interpretation of the request, then the request will fail.  If
> the header is just optional fluff (User-Agent, Referer), then the
> actually or implied missing header can be ignored, no harm done.
>
> I agree that the empty Referer header violates the specified syntax.
> The question is, what should the recipient do about it?  A server could
> parse all headers strictly according to the specified syntax and return
> a 400 Bad Request response if it sees an error.  Or, it could adopt the
> more common tolerant Internet behavior and ignore the malformed header.
>
> I seem to have encountered, for the first time of which I'm aware, an
> example of the former, and it surprised me.
>
> Dave Kristol
>
>

Received on Tuesday, 26 May 1998 12:29:41 UTC