Re: HTTP 404 Served As text/plain UPDATE
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
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
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 - 1.100
> +++ modules/mappers/mod_negotiation.c 26 Mar 2002 20:54:33 -
> @@ -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
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 - 1.100
+++ modules/mappers/mod_negotiation.c 26 Mar 2002 20:54:33 -
@@ -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
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
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
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
