Closed Bug 96536 Opened 23 years ago Closed 21 years ago

302 redirect after clicking a link ignores domain in redirect, goes to linking domain instead

Categories

(Core :: Networking: HTTP, defect, P3)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
Future

People

(Reporter: darin.moz, Assigned: darin.moz)

References

(
URL
)

Details

tested with the 2001081514 linux trunk build (also noticed this problem in a
CVS debug build from yesterday).

1) go to http://bugzilla.mozilla.org/show_bug.cgi?id=96440

2) click on the URL link above the bug Summary

3) notice that the server responds with a Page Not Found error

4) notice also that the URL bar shows the WRONG URL:
   http://bugzilla.mozilla.org/fc/2-118,209-119,675480
   instead of
   http://news.wideopen.com/r/2-118,209-103,16673606
cool. this also occurs in nc4.78
-> networking: http

Use http://webtools.mozilla.org/web-sniffer/ to see what Mozilla sees when you 
click the link to http://news.wideopen.com/r/2-118,209-103,16673606.
Assignee: asa → neeti
URL: http://bugzilla.mozilla.org/show_bug.... → http://news.wideopen.com/r/2-118,209-...
Component: Browser-General → Networking: HTTP
QA Contact: doronr → tever
Summary: URL link click incorrectly resolved to bugzilla.mozilla.org → 302 redirect after clicking a link ignores domain in redirect, goes to linking domain instead
Maybe it is somehow related but after clicking on

http://www.gingerall.cz/perl/rd?url=sablot/Sablot-0.70.tar.gz

Mozilla prompts me if i want to save file and then nothing happens (linux
2001102421).
to darin, with love.
Assignee: neeti → darin
-> moz 1.0.1
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.0.1
Target Milestone: mozilla1.0.1 → ---
mass futuring of untargeted bugs
Target Milestone: --- → Future
sniffer :


HTTP/1.1 302 Moved TemporarilyCRLF
Date: Sat, 08 Jun 2002 14:04:04 GMTCRLF
Server: Oracle9iAS (1.0.2.2) Containers for J2EECRLF
Content-Length: 225CRLF
Set-Cookie: JSESSIONID=COEHHPNLCGCF; Path=/CRLF
Cache-Control: privateCRLF
Connection: CloseCRLF
Content-Type: text/plainCRLF
Location: http://headlinewatch.com/fc/2-118,209-119,675480CRLF
CRLF
<HTML><HEAD><TITLE>Redirect to
http://headlinewatch.com/fc/2-118,209-119,675480</TITLE></HEAD><BODY><A
HREF="http://headlinewatch.com/fc/2-118,209-119,675480">http://headlinewatch.com/fc/2-118,209-119,675480</A></BODY></HTML>
Using: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630

I just came across a problem with 302 redirects, and found this bug, which seems
to be the same.   But seen as it doesn't have activity since a year ago, I
decided to write this.

I have seen this bug with this URL: (it is really long...)
http://www.unionfenosamultiservicios.com/servlet/com.soluzionasf.latienda.EstadisticasBanner.EstadisticasBanner?descripcion=Promociones%20socios&fechaAlta=25/07/2003&tipo=2&urlDest=/Club/promociones/contenidos.jsp?donde=club

The server returns the following: 

 HTTP/1.1 302 Moved Temporarily
 Server: Netscape-Enterprise/3.6 SP2
 Date: Mon, 01 Sep 2003 22:22:17 GMT
 Location: /Club/promociones/contenidos.jsp?donde=club
 Content-type: text/html
 Age: 21
 Connection: close

but Mozilla does nothing.  It does not follow the redirect and load the
/Club/promo...etc... page.
I am using Mozilla 1.4 on Linux.

However, if I visit the same page with IE or Opera 7.11, or even wget, the
redirect is properly taken into account and the page in the "Location:" field is
requested and loaded.

The bug is reproducible every time.

Actually, reading RCF 2616, section 10.3.3, is not clear to me that a user-agent
should actually follow 302 redirects automatically, so I don't know if this is a
bug as far as the standard is concerned.

The fact is that there are sites (like the one I came across in this bug) that
seem to rely on the user-agent to automatically redirect to the given Location.  

pedro: actually, the bug you are seeing is quite different.  in the case of the
URL you gave, Mozilla correctly follows the redirect.  however, the web site
responds with a 205 status code, which means that the browser should not load
anything new, but should reset any form elements on the previous page.  other
browsers like IE and Opera mistakenly treat 205 as 200.  if you have the means,
you should contact the site administrator and inform them of the problem with
their site.  hopefully, they will fix their site.  if you do not have the
opportunity to do this, then please file a new mozilla bug against "Tech
Evangelism" and someone else from the Mozilla community will (eventually) follow
up with the site to get the problem corrected.
Darin:  thanks for your explanation.  I looked at the network trace again, and
saw that the redirect is indeed happening.  I have used your explanation to
email the site and explain that their site has a problem (I gave them a detailed
explanation of the problem).   We'll see if they listen.    Thanks again,   and
sorry for placing my comment on this bug, since it turns out it is not related.

-> defaults.

Isn't this problem fixed via bug 30783?
Status: ASSIGNED → NEW
QA Contact: tever → httpqa
marking WORKSFORME.  original bug report is no longer valid... link is dead. 
problem i think is fixed as benc mentioned.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
VERIFIED: wfm
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.