[Web-SIG] Servers ignoring application-supplied headers

[Phillip J. Eby]

At 01:20 AM 8/27/04 +0100, Jim Dabell wrote:

> > In general, the server or gateway is responsible for ensuring that correct
> > headers are sent to the client: if the application omits a needed header,
> > the server or gateway *should* add it.  For example, the HTTP ``Date:`` and
> > ``Server:`` headers would normally be supplied by the server or 
> gateway.  If
> > the application supplies a header that the server would ordinarily supply,
> > or that contradicts the server's intended behavior (e.g. supplying a
> > different ``Connection:`` header), the server or gateway *may* discard the
> > conflicting header, provided that its action is recorded for the benefit of
> > the application author.
>
>Is this wise?  It's not really the WSGI's job to nanny the application and
>make sure it does the right thing.  I can see the case for supplying default
>values, but simply throwing away something it's specifically been asked to
>use seems rather shortsighted.  WSGI authors aren't perfect, and it's far to
>easy to end up in a situation where application developers are stuck behind a
>clueless WSGI that insists on ignoring certain things because it thinks it's
>the right thing to do.  It seems to me that if the application developers
>want to do something, WSGI shouldn't make it intentionally impossible for
>them to do.
>
>The worst that is likely to happen is the application developer tries
>something and it breaks, so he doesn't try it again, right?

Fair enough.  I should probably narrow that phrasing more specifically to 
the issue I had in mind.  Specifically, it shouldn't be the application's 
job to control whether the connection will persist or not.  That's 
something that (IMO) belongs squarely in the server/gateway's bailiwick.  I 
guess I was just trying to get away without studying the 
keep-alive/connection header specs enough to be more specific.  :)

It may be that there are other response headers that similarly should be 
the exclusive preserve of the server, but I don't know what they are at 
present.