[Web-SIG] Servers ignoring application-supplied headers
Phillip J. Eby
pje at telecommunity.com
Fri Aug 27 06:07:14 CEST 2004
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.
More information about the Web-SIG
mailing list