Re: [PATCH] error responses have wrong headers

["Roy T. Fielding" <fi...@kiwi.ICS.UCI.EDU>]

>    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

Re: [PATCH] error responses have wrong headers

[Dean Gaudet <dg...@arctic.org>]

On Mon, 5 May 1997, Roy T. Fielding wrote:
> 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().

Bleh!  This is a mess.  If we do what you suggest, and also tweak mod_neg
to move Alternates and Vary to err_headers_out, have we covered all the
bases?

Are these the semantics then?

    headers_out		headers sent only with 200..299 responses
    err_headers_out	headers sent with all responses

Dean