On Tue, 26 Mar 2002, Bill Stoddard wrote:
> No comments on whether this patch is correct in concept or not. However, it is
>definitely
> broken if you do not use ap_set_content_type() to set the content type.
By the way, why don't we enforce this type of thing by making these
portions of the
On Tue, 26 Mar 2002, Bill Stoddard wrote:
> No comments on whether this patch is correct in concept or not. However, it is
>definitely
> broken if you do not use ap_set_content_type() to set the content type.
yeah - i did not put [PATCH] in the subject because this is not a
suggested patch t
No comments on whether this patch is correct in concept or not. However, it is
definitely
broken if you do not use ap_set_content_type() to set the content type.
Bill
> On Tue, 26 Mar 2002, Jerry Baker wrote:
>
> > Jerry Baker wrote:
> > >
> > > I just noticed something about this problem. If
On Tue, 26 Mar 2002, Jerry Baker wrote:
> Jerry Baker wrote:
> >
> > I just noticed something about this problem. If you request
> > /nonexistentfile.html then the error response is sent back with
> > text/html, but if you request /nonexistentfile then it still comes back
> > as text/plain.
> >
Jerry,
thanks for the detailed analysis... sure sounds like you've hit the nail on
the head.
When we 'tag' .34 - we won't be rolling it. I will personally be looking at
this quirk in the next day or two, and so may others. If a patch is prepared
that 'fits' [increases stability - doesn't
Jerry Baker wrote:
>
> I just noticed something about this problem. If you request
> /nonexistentfile.html then the error response is sent back with
> text/html, but if you request /nonexistentfile then it still comes back
> as text/plain.
>
> --
> Jerry Baker
Not only that. If you request /non
I just noticed something about this problem. If you request
/nonexistentfile.html then the error response is sent back with
text/html, but if you request /nonexistentfile then it still comes back
as text/plain.
--
Jerry Baker
