> -----Ursprüngliche Nachricht-----
> Von: Jim Jagielski
> Gesendet: Donnerstag, 15. Dezember 2005 17:02
> An: dev@httpd.apache.org
> Betreff: Re: AW: 2.2 mod_http_proxy and "partial" pages
>
>
{..cut..]
> >
> > Sorry, but I think I have to disagree.
> > There is nothing that can be handled anymore since the headers had
> > been sent to the client.
> > The only part of the chain that handles error buckets so
> far is the
> > http header filter which is gone at
> > this point of time.
>
> IMO, that's the problem... The core output filter should be
> aware of this error. Not sure if "magically" noticing this
> when removing empty buckets is the right solution...
>
No problem. Let's discuss where to place this. I just placed it
into the remove_empty_buckets function as I wanted to avoid to run
a loop twice over the brigade. I think I need some kind of loop
because otherwise I might miss this bucket (e.g. in remove_empty_bucket,
if there are other meta buckets before the error bucket).
Having the check only in writev_nonblocking might lead to a miss of
this bucket.
Anyway I detected another problem that is also there with my current
patch proposal. I think we need to make the ap_http_chunk_filter aware of this
error bucket. Otherwise it will add the "closing" zero length chunk to
the response once it sees the eos bucket. This would give the client the
impression that the response had been correct and complete (provided
that the reponse was in chunked encoding). If the client is a proxy
this could lead to a cache poisoning. So my proposal is that we do
*not* insert the "closing" zero length chunk to signal the client
that the response is not complete and broke in the middle.
Regards
Rüdiger
