You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jerry Baker <je...@weirdness.com> on 2002/03/26 09:36:39 UTC
HTTP 404 Served As text/plain UPDATE
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
Re: HTTP 404 Served As text/plain UPDATE
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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 restructure a ton of code] then
we will
'roll it in' to .34. Agreed that this isn't nice behavior, but also
recognize that
this is one bug in many, and many are now fixed and many others may yet
be unspotted. We want to get something into folks hands, even if it is
only 'alpha' quality. Release early, release often assures that many more
bugs are fixed much more quickly.
Bill
At 01:00 PM 3/26/2002, you 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 Baker
>
>Not only that. If you request /nonexistentfile.exe, it gets sent back as
>application/octet-stream. The ErrorDocument is being returned with
>whatever content-type matches the file extension of the requested
>document. I doubt many people want to download the ErrorDocument in the
>case that they request a non-existent application/octet-stream URI.
>
>--
>Jerry Baker
Re: HTTP 404 Served As text/plain UPDATE
Posted by st...@covalent.net.
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 structure opaque? There are a bunch of cases, notably in
the request rec, where there are rules like this that are not enforced by
the compiler.
sterling
Re: HTTP 404 Served As text/plain UPDATE
Posted by st...@covalent.net.
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 to fix the problem - but to help shed light on the
problem. The real problem, i think, is that the content type is not being
propagated up in this case. The module should not be responsible for this
decision.
sterling
Re: HTTP 404 Served As text/plain UPDATE
Posted by Bill Stoddard <bi...@wstoddard.com>.
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 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 /nonexistentfile.exe, it gets sent back as
> > application/octet-stream. The ErrorDocument is being returned with
> > whatever content-type matches the file extension of the requested
> > document. I doubt many people want to download the ErrorDocument in the
> > case that they request a non-existent application/octet-stream URI.
>
>
> yeah - the sub request content type is getting set by negotiation, but it
> is not being propagated up. i am not sure how this is supposed to take
> place, but the following patch actually makes the content type set
> properly in my test cases..... although i don't think its the right fix -
> isn't that content type supposed to be propagated? i know this stuff is
> kinda whacky - maybe this sheds some light on the situation. anyways
> here's the patch
>
> Index: modules/mappers/mod_negotiation.c
> ===================================================================
> RCS file: /home/cvspublic/httpd-2.0/modules/mappers/mod_negotiation.c,v
> retrieving revision 1.100
> diff -u -r1.100 mod_negotiation.c
> --- modules/mappers/mod_negotiation.c 20 Mar 2002 17:41:55 -0000 1.100
> +++ modules/mappers/mod_negotiation.c 26 Mar 2002 20:54:33 -0000
> @@ -942,10 +942,13 @@
> }
> else if (!strncmp(buffer, "content-type:", 13)) {
> struct accept_rec accept_info;
> + request_rec *tmp_req;
>
> get_entry(neg->pool, &accept_info, body);
> set_mime_fields(&mime_info, &accept_info);
> has_content = 1;
> + for( tmp_req = r; tmp_req != NULL; tmp_req = tmp_req->prev )
> + tmp_req->content_type = mime_info.mime_type;
> }
> else if (!strncmp(buffer, "content-length:", 15)) {
> mime_info.bytes = atol(body);
>
Re: HTTP 404 Served As text/plain UPDATE
Posted by st...@covalent.net.
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 Baker
>
> Not only that. If you request /nonexistentfile.exe, it gets sent back as
> application/octet-stream. The ErrorDocument is being returned with
> whatever content-type matches the file extension of the requested
> document. I doubt many people want to download the ErrorDocument in the
> case that they request a non-existent application/octet-stream URI.
yeah - the sub request content type is getting set by negotiation, but it
is not being propagated up. i am not sure how this is supposed to take
place, but the following patch actually makes the content type set
properly in my test cases..... although i don't think its the right fix -
isn't that content type supposed to be propagated? i know this stuff is
kinda whacky - maybe this sheds some light on the situation. anyways
here's the patch
Index: modules/mappers/mod_negotiation.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/modules/mappers/mod_negotiation.c,v
retrieving revision 1.100
diff -u -r1.100 mod_negotiation.c
--- modules/mappers/mod_negotiation.c 20 Mar 2002 17:41:55 -0000 1.100
+++ modules/mappers/mod_negotiation.c 26 Mar 2002 20:54:33 -0000
@@ -942,10 +942,13 @@
}
else if (!strncmp(buffer, "content-type:", 13)) {
struct accept_rec accept_info;
+ request_rec *tmp_req;
get_entry(neg->pool, &accept_info, body);
set_mime_fields(&mime_info, &accept_info);
has_content = 1;
+ for( tmp_req = r; tmp_req != NULL; tmp_req = tmp_req->prev )
+ tmp_req->content_type = mime_info.mime_type;
}
else if (!strncmp(buffer, "content-length:", 15)) {
mime_info.bytes = atol(body);
Re: HTTP 404 Served As text/plain UPDATE
Posted by Jerry Baker <je...@weirdness.com>.
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 /nonexistentfile.exe, it gets sent back as
application/octet-stream. The ErrorDocument is being returned with
whatever content-type matches the file extension of the requested
document. I doubt many people want to download the ErrorDocument in the
case that they request a non-existent application/octet-stream URI.
--
Jerry Baker