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: VERIFIED FIXED
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://www.freeprachar.com
Keywords: Beginner
Depends on:
Blocks:
 
Reported: 2004-04-28 14:42 UTC by Mark Tranchant
Modified: 2019-11-20 10:11 UTC (History)
1 user (show)



Attachments
lottery (16.55 KB, text/html)
2019-08-31 11:48 UTC, Lottery Sambad
Details

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).
Comment 11 Christophe JAILLET 2018-12-22 10:18:09 UTC
Please stop spamming.
Thx
Comment 12 nick 2019-10-26 14:30:14 UTC
ok
Comment 13 nick 2019-10-26 14:30:46 UTC
ok(In reply to André Malo from comment #7)
> 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.

ok