203631 - Host header should not include the default port for compatibility with broken servers

Status: RESOLVED WORKSFORME

(Core :: Networking, defect, P3)

Description

[dave cannizzaro]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312

the url contains a Base64 encoded string (RFC 1521). It seems that  the equals
signs at the end of the string, are disturbing the request.
the same url works fine with IE and Opera

Reproducible: Always

Steps to Reproduce:
1.just click on the provided link
2.
3.

Actual Results:  
an error is provided by the application.

Expected Results:  
a page should be displayed

Comment 1

[Hermann Schwab]

Mozilla gives me following error message, Opera7 displays an empty page with a
gif, seems correct if you look at the source.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030425  shows:

Forbidden (403)
You have requested data that the server has decided not to provide to you. Your
request was understood and denied.
Not Found (404)
The file that you requested could not be found on this server. If you provided
the URL, please check to ensure that it is correct. If you followed a hypermedia
link, please notify the administrator of that server of this error.

Comment 2

[Matthias Versen [:Matti]]

-> HTTP

Comment 3

[Boris Zbarsky [:bzbarsky]]

That url has a session ID embedded.  If anyone tries to follow it, it'll just
give a 403, since that person does not have the right IP for the session.

Comment 4

[Darin Fisher]

dave: can you capture packet traces of Mozilla and IE/Opera loading that page? 
there's a handy tool available from www.ethereal.com (available for windows and
most platforms) that can help you do this.  if you aren't able to do this, then
no problem.  but, it sure would help us if you could ;-)

just save each capture to disk and upload the files to this bug report.  thx!

Comment 5

[dave cannizzaro]

Attachment: opera logfile captured with ethereal

as you wished

Comment 6

[dave cannizzaro]

Attachment: ie 6.0 logfile captured with ethereal

as you wished

Comment 7

[dave cannizzaro]

Attachment: mozilla logfile captured with ethereal

as you wished

Comment 8

[dave cannizzaro]

i added teh desired log files with the required tool ethereal

Comment 9

[Darin Fisher]

dave: awesome! thank you! i'll take a look to see what differs...

Comment 10

[Darin Fisher]

so, both opera and mozilla issue the exact same HTTP request line, but for some
reason the server just doesn't like the full HTTP request from mozilla.  one
difference is the host header.  mozilla sends this:

  Host: www.homegate.ch:80

while opera sends this:

  Host: www.homegate.ch

this difference should not matter; however, i seem to recall fixing a bug well
over a year ago to make sure that mozilla does not send the default port number
in the Host header because of the fact that some servers misunderstand it.

dave: can you try loading the URL without the ":80"?

Comment 11

[dave cannizzaro]

darin,
your right without the portnumber the request provides the correct result.
so, what will be your next steps?

Comment 12

[Darin Fisher]

-> walter

Comment 13

[Walter Shen]

Attachment: Patch

Adds some code to avoid sending in the default port number (for both SSL and
not SSL).

Comment 14

[Walter Shen]

Attachment: patch

New Patch.  Accomplishes the same things as the old one, but a little more
efficiently.

Comment 15

[Walter Shen]

Comment on attachment 127913 [details] [diff] [review]
patch

Review, I think?

Comment 16

[Darin Fisher]

Comment on attachment 127913 [details] [diff] [review]
patch

r+sr=darin (looks good walter.. thx!)

Comment 17

[Darin Fisher]

actually, i started thinking about this bug some more... and a question came up:
why isn't the default port striped from the URL inside nsStandardURL::Init?  it
almost seems as if the URL has not been created properly.

this bug is easily reproducible simply by loading http://anyhost:80/ and
watching a network packet trace or HTTP log.

one option would be to try to fix this by modifying the code in
nsStandardURL::BuildNormalizedSpec to have it set mPort = -1 when mPort ==
mDefaultPort.  i'm not sure if that would break other things yet... i need to
think about it for a little while ;-)

Comment 18

[Darin Fisher]

sorry, this one slipped off my radar...

Comment 19

[Darin Fisher]

-> default owner

Comment 20

[Wayne Mery (:wsmwk)]

testcase URL no longer works

Comment 21

[Matthias Versen [:Matti]]

Jason, Honza : Do you think that we should take the patch or if we still want to do a more general solution ?

Comment 22

[Jason Duell]

> Do you think that we should take the patch or if we still want to do
> a more general solution ?

Patch doesn't apply--the Init code doesn't look like this any more at all.

Are we even sure this is still an issue?  No comments from users in 4 years, and the code has changed.   Need to verify it's even still an open bug.

Comment 23

[Matthias Versen [:Matti]]

This seems to be wfm if I follow comment#17 and load http://host:80 either with the URL bar or as link in a html document. The port is stripped from the Host Header.
Sorry for the noise