51517 - URL parsing doesn't handle bogus Location: headers that ns4.7/ie do

Status: RESOLVED WONTFIX

(Core :: Networking, defect, P5)

Description

[Randell Jesup [:jesup] (needinfo me)]

FreeBSD 4.1 20000905xx (evening)

Got to this page.  At the bottom of the article, click "Forward this article to
an associate".  Note that it takes you to the main www.digitalbroadcasting page.
 In ns4.x and IE, it works correctly.

Note the typo(?) in the redirect from IIS.

/home/jesup> telnet www.digitalbroadcasting.com 80
Trying 209.185.177.155...
Connected to www.digitalbroadcasting.com.
Escape character is '^]'.
get
http://www.digitalbroadcasting.com/content/news/sendpage.asp?headline=Are+chips+falling+out+of+DTV+mainstream%3F&bodyURL=http%3A%2F%2Fwww%2Edigitalbroadcasting%2Ecom%2Fcontent%2Fnews%2Farticle%2Easp%3FDocID%3D%7B0B9EFF82%2D7126%2D11D4%2D8C58%2D009027DE0829%7D%26Bucket%3D%26Featured%3D&hubURL=/content/news&hubdesc=News+%26+Analysis&Feature=-1&forwardedURL=%2Fcontent%2Fnews%2Fforwarded%2Easp%3Fheadline%3DAre%2Bchips%2Bfalling%2Bout%2Bof%2BDTV%2Bmainstream%253F%26bodyURL%3Dhttp%253A%252F%252Fwww%252Edigitalbroadcasting%252Ecom%252Fcontent%252Fnews%252Farticle%252Easp%253FDocID%253D%257B0B9EFF82%252D7126%252D11D4%252D8C58%252D009027DE0829%257D%2526Bucket%253D%2526Featured%253D%26hubURL%3D%2Fcontent%2Fnews%26hubdesc%3DNews%2B%2526%2BAnalysis
HTTP/1.1

HTTP/1.1 302 Moved Temporarily
Server: Microsoft-IIS/5.0
Date: Wed, 06 Sep 2000 15:20:08 GMT
Set-Cookie: SITESERVER=GUID=F270FC365D194218BD47777C53EFA641; expires=Fri,
01-Jan-2010 00:00:00 GMT; path=/; domain=.digitalbroadcasting.com
Location:
http://www.digitalbroadcasting.comhttp://www.digitalbroadcasting.com/content/news/sendpage.asp?headline=Are+chips+falling+out+of+DTV+mainstream%3F&bodyURL=http%3A%2F%2Fwww%2Edigitalbroadcasting%2Ecom%2Fcontent%2Fnews%2Farticle%2Easp%3FDocID%3D%7B0B9EFF82%2D7126%2D11D4%2D8C58%2D009027DE0829%7D%26Bucket%3D%26Featured%3D&hubURL=/content/news&hubdesc=News+%26+Analysis&Feature=-1&forwardedURL=%2Fcontent%2Fnews%2Fforwarded%2Easp%3Fheadline%3DAre%2Bchips%2Bfalling%2Bout%2Bof%2BDTV%2Bmainstream%253F%26bodyURL%3Dhttp%253A%252F%252Fwww%252Edigitalbroadcasting%252Ecom%252Fcontent%252Fnews%252Farticle%252Easp%253FDocID%253D%257B0B9EFF82%252D7126%252D11D4%252D8C58%252D009027DE0829%257D%2526Bucket%253D%2526Featured%253D%26hubURL%3D%2Fcontent%2Fnews%26hubdesc%3DNews%2B%2526%2BAnalysis&VNETCOOKIE=NO

Comment 1

[Jeffrey Baker]

I don't see any reason why we should handle this.  Clearly
"www.digitalbroadcasting.comhttp" is not a valid hostname.  I can't think of any
way to hack around this that is guaranteed to not break something else

This is the second example we've seen of IIS 5.0 fucking with the HTTP
protocol.  The other example was the bogus hotmail redirect that we
unfortunately hacked around.

Comment 2

[Gagan]

I agree. 

Comment 3

[Tom Everingham]

verified

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

I know this is verified wontfix; however this does affect at a minimum all of
digitalbroadcasting.com, and perhaps all other verticalnet sites (digital
broadcasting is a verticalnet site).  It's also interesting that 4.x and IE both
support this; I assume they do search for the last http:// and start from there;
or do that after an initial failure.  Purity is all well and good, but reviewers
and users aren't going to know or care that verticalnet (or Microsoft IIS) is
the one screwed up; they'll just know that IE works and Mozilla doesn't.

Comment 5

[Jeffrey Baker]

The same argument could be extended to say that Mozilla should support <LAYER>,
since reviewers and users don't know or care about standards, and will be pissed
when SomeStupidSite.com doesn't work.

This "bug" cannot be fixed without breaking legitimate URL schemes.  If you
disagree, post your algorithm here.

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

Ok:
Ignoring data after a '?', search for the last http:// in the URL.
http:// in the middle of a URL (except after a ?) would be invalid I think;
please correct me if I'm wrong. 

"http://hostname:port/path" is valid in all cases
"http://hostname://path" works under ns4.x/IE, but NOT mozilla
"http://hostnamehttp://path" works under ns4.x/IE ONLY in Location: (not from
address widget) (I believe; only ns4.x was tested)
"http://hostname/path://path" doesn't appear to work under 4.x

Since we'd be searching for http://, not just ://, this would have no lossage
that I can see.  It would be a browser-compatibility hack, but unlike LAYER, in
this case both IE and ns4.x support it.

Comment 7

[Jeffrey Baker]

Okay, I can almost buy that.  "//" is invalid except exactly after scheme ":". 
Further, ":" is reserved and cannot be used in paths.

The only hole I see in your algorithm is that "http://" is a valid fragment. 
That is, you could have:

http://host/path#http://blahblah/blah

And that would be perfectly valid.  So you could restart URI parsing if you saw
"<scheme>://" at any point after charater zero and before "?" or "#".

I still can't imagine anyone spending time to change this.

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

Ok, reopening at priority 5, milestone Future.  I may take a shot at this if I
have some free moments for amusement.

Comment 9

[benc]

mass move, v2.
qa to me.

Comment 10

[benc]

+clean-report, -> current default owners.
-> recommending wont'fix

Maybe the bugs are in HTTP, but I don't think I've ever seen a duplicate of this
bug...

Comment 11

[Doug Turner (:dougt)]

mass reassigning to nobody.

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

This broken behavior is no longer relevant, and modern browsers don't accept this broken usage anymore.