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
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/...
Depends on:
Reported: 2004-04-28 14:42 UTC by Mark Tranchant
Modified: 2018-11-09 09:17 UTC (History)
0 users


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

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

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
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

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 james lara 2018-08-28 13:15:57 UTC
its great post and help me alot. please keep continue posting articles on your great site.
Comment 12 james lara 2018-09-03 07:33:28 UTC
Thanks so much for your kind words. It means the world best article :)

Comment 13 Jack 2018-10-01 19:54:39 UTC
This article helped me and business out a lot - thank you
Comment 14 Jack 2018-10-14 12:18:29 UTC
Very grateful that you shared this content! 

Comment 15 thanhlycuongphat 2018-11-09 09:17:53 UTC
https://thanhlycuongphat.com/ thanh ly may tinh, giai phap phong net tron goi