>Number: 5455 >Category: protocol >Synopsis: Lynx misinterprets Content-Location >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: open >Class: change-request >Submitter-Id: apache >Arrival-Date: Fri Dec 10 16:20:03 PST 1999 >Last-Modified: >Originator: [EMAIL PROTECTED] >Organization: apache >Release: >Environment: n/a >Description: To quote someone else: Client Bug! Not an apache bug! I couldn't find the appropriate category for client bugs.
All known Lynx versions (well, at least since 2-5, 1996) have a bug that causes a "Content-Location:" header field to be mis-recognized as "Location:" in redirection responses, if the "Content-Location:" precedes the "Location:". (This applies only to messages with redirection status codes 301,302,etc., where the Lynx code takes some shortcuts instead of doing full header parsing.) This was never discovered until recently - apparently such a combination of header fields hasn't been common. Recently the problem was reported to the lynx-dev list. Please see http://www.flora.org/lynx-dev/html/month1199/msg00370.html and http://www.flora.org/lynx-dev/html/month1199/msg00383.html for the original report, including headers. (It appears that conneg creates redirection messages with "Content-Location:"?) This is being corrected in the current Lynx development code. Apache isn't doing anything wrong here. But could Apache work around the problem, for those Lynx copies out there? >How-To-Repeat: Access <http://www.disabilitytimes.com/go/headline?url=http://www.foo.com> with any moderately recent version of Lynx. You'll end up at the wrong page after the redirection(s). >Fix: (a) Always send any "Location:" header fields before any "Content-Location:", in all responses (all 30x responses would be enough, x > 0). Or (b) something like (a), or perhaps suppressing "Content-Location:", under control of BrowserMatch. >Audit-Trail: >Unformatted: [In order for any reply to be added to the PR database, you need] [to include <[EMAIL PROTECTED]> in the Cc line and make sure the] [subject line starts with the report component and number, with ] [or without any 'Re:' prefixes (such as "general/1098:" or ] ["Re: general/1098:"). If the subject doesn't match this ] [pattern, your message will be misfiled and ignored. The ] ["apbugs" address is not added to the Cc line of messages from ] [the database automatically because of the potential for mail ] [loops. If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request from a ] [developer. Reply only with text; DO NOT SEND ATTACHMENTS! ]