httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ICS.UCI.EDU>
Subject Re: [PATCH] error responses have wrong headers
Date Tue, 06 May 1997 00:33:46 GMT
>    Hmm.  Again, I haven't traced it, but isn't the r->headers_out
>    table supposed to be ignored, and only r->err_headers_out sent, on
>    an error?

That changed when I did the big header table patch.  The problem is that
the code cannot enforce HTTP compliance if their are two tables being
output instead of just one, so it merges the tables first.  We could
return to the old behavior simply by clearing the r->headers_out
table (using a new table_empty() function, please) before calling
send_http_header(r) in http_protocol.c:send_error_response().

The reason I did not do that before is because there is no documented
behavior for where a module should place headers to be output, and it
seemed more reasonable to just require that the modules not be sloppy
about what they are sending. *shrug*

If we do change it back, then we also need to revert the change in
mod_negotiation (placing Alternates and Vary in err_headers_out again).

>    {Sigh} More stuff for 1.2.1.. or do we want this in 1.2?

In 1.2, or not at all.

>    I seem to recall noticing that some of the core routines
>    (set_http_header() in particular, I think - I just woke up, so I may
>    be misremembering) overrides the r->[err_]headers_out table and do
>    things themselves.  Particularly for things like Content-type.
>    Maybe that should be normalised at some point, so *every*thing uses
>    the tables?

They *do* use the tables.  The override is on purpose, to enforce HTTP
compliance for those fields that the server considers "sacred".  Note
that r->content_type overrides any existing Content-Type field for
historical reasons, since that is how the API was designed to set a
content-type before the existance of header field tables.

....Roy

Mime
View raw message