httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Lu <chaos...@gmail.com>
Subject Re: stop copying footers to r->headers_in?
Date Mon, 12 May 2014 17:03:28 GMT
Both the things you caught were probably just errors I made in manually
merging the patch into 2.2.x; here's a revised version, just in case.
Thanks for the review.

I'm not really clear on the error-notes discussion. It makes sense that we
wouldn't care too much if we don't save the ones from reading the headers,
since we would have errored earlier if they were set. What happens
currently if there's an error reading the trailers and we are not merging
the trailers? Seems like the error-notes would just get overwritten with
nothing, in the general case, and they wouldn't be able to be used anywhere.


On Sun, May 11, 2014 at 3:55 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:

> On Sun, May 11, 2014 at 6:35 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
> > Restoring the status and notes (set before the body is read) seems
> > unconditional to me.
>
> Well, actually I'm not really sure whether we should preserve or
> overwritte the "error-notes" here.
>
> In most cases (but PROXYREQ_RESPONSE discussed below), we are still
> reading the request.
> If an error is raised by ap_get_mime_headers(), we probably want to
> respond with a 4xx status and the corresponding error-notes (from this
> call).
> Moreover, the original "error-notes" (from the headers' parsing) is
> very likely to be unset here (or we would have responded with that
> error at that time).
>
> However, when ap_http_filter() is called in PROXYREQ_RESPONSE mode, we
> probably need to discard the forwarded response's trailers'
> "error-notes", since the client is not the culprit.
>
> Maybe we should distinguish (at least) these 2 "modes" in the final patch.
>

Mime
View raw message