Bug 28657 - mod_negotiation should not store Content-Location header as an error header
Summary: mod_negotiation should not store Content-Location header as an error header
Status: CLOSED WONTFIX
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_negotiation (show other bugs)
Version: 2.0-HEAD
Hardware: PC Linux
: P3 minor (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL: http://bradchoate.com/weblog/2004/04/...
Keywords:
Depends on:
Blocks:
 
Reported: 2004-04-28 14:42 UTC by Mark Tranchant
Modified: 2004-11-16 19:05 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Tranchant 2004-04-28 14:42:04 UTC
I'm using MultiViews for content negotiation, as described at
http://tranchant.plus.com/notes/multiviews.

I notice that mod_negotiation adds a Content-Location header to each request,
which reveals the actual filename chosen. The URL given above details the
authors discovery that mod_negotiation adds this header to some sort of error
header array, necessitating use of the ErrorHeader directive to remove it with
Apache 1.3.

ErrorHeader has been removed in 2.0, and a simple Header directive doesn't work.
There appears to be no way to get Apache not to produce the Content-Location header.
Comment 1 André Malo 2004-04-28 14:48:11 UTC
Just a minor detail. It was not removed, but not ported yet ;-). The backport
from 2.1 is already in voting stage.
Comment 2 Mark Tranchant 2004-04-28 15:10:44 UTC
Summary simplified by someone else. I'm not sure whether the bug is "no
ErrorHeader directive", or "mod_negotiation should add Content-Location as a
normal header, not an error header".
Comment 3 Joshua Slive 2004-04-28 16:21:04 UTC
errorheader doesn't actually mean that the header is sent only on errors.  In
fact, it means the header is sent both on normal responses and on errors.
Comment 4 Mark Tranchant 2004-04-28 18:49:57 UTC
Understood, but the way it is stored prior to sending means that the Header
directive cannot modify it. I'd argue that it should be able to - as it is not
an error.
Comment 5 André Malo 2004-05-14 10:30:56 UTC
r->err_headers_out is the right place, because it must be sent always, if it's
sent at all.
Comment 6 Mark Tranchant 2004-05-14 10:58:58 UTC
I'm not happy with that. The HTTP spec says it SHOULD be sent out for negotiated
documents, not MUST. I have (I believe) good reason for not wanting it sent - I
don't want future requests direct to the actual document, as that may generate a
404.

If you WONTFIX this again, I'll shut up, but I think this needs fixing.
Comment 7 André Malo 2004-05-14 11:53:17 UTC
You changed the report to change the implementation, which is correct. Thatsway
wontfix.
It has nothing to do with SHOULD or MUST clauses in the RFC.

By the way, *I* was the guy who suggested the backport, because of exactly the
problem, you're encountering.
Comment 8 Mark Tranchant 2004-05-14 11:55:02 UTC
Accepted WONTFIX (private mail discussion). Will await ErrorHeader backporting.
Comment 9 André Malo 2004-06-17 21:06:12 UTC
FYI: we've changes the implementation in 2.1 with respect to the misnaming of
ErrorHeader. Now there's a new attribtute für Header, which controls the
behaviour and is hopefully more intuitive. See
<http://httpd.apache.org/docs-2.1/mod/mod_headers.html#header>.

However, the whole change was suggested for backport.
Comment 10 André Malo 2004-08-19 22:58:47 UTC
Done. (will be in 2.0.51).