Closed
Bug 68426
Opened 24 years ago
Closed 24 years ago
W3C CUAP: Handle the fragment identifier when request is redirected
Categories
(Core :: Networking, defect)
Core
Networking
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: gerv, Assigned: neeti)
References
()
Details
[ This bug is one of the recommendations in the W3C's "Common User Agent Problems" document, URL above. One bug has been filed on each recommendation, for deciding whether we do it and, if not, whether we should. ] 4.1 Handle the fragment identifier of a URI when the HTTP request is redirected. When a resource (URI1) has moved, an HTTP redirect can indicate its new location (URI2). If URI1 has a fragment identifier #frag, then the new target that the user agent should be trying to reach would be URI2#frag. If URI2 already has a fragment identifier, then #frag must not be appended and the new target is URI2. Wrong: Most current user agents do implement HTTP redirects but do not append the fragment identifier to the new URI, which generally confuses the user because they end up with the wrong resource.
Updated•24 years ago
|
Hardware: PC → All
Comment 1•24 years ago
|
||
This works for me. Try e.g. http://vcd-muenchen.de/mvv-tarif-99.html#verbesserungen . It gives an HTTP 301 status and leads to http://vcd-muenchen.de/archiv/1999/mvv-tarif-99.html#verbesserungen .
Comment 2•24 years ago
|
||
Works for me, too, in Mozilla 0.8 on NT4. Marking so.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•