713472 - URI parsing: semicolon in authority

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Daniel Stenberg [:bagder]]

User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2

Steps to reproduce:

Entered a malformed URI into the URL field of Firefox (Iceweasel 8.0-3+b1 on Debian to be specific, I don't know what Core/Networking version this corresponds to) using this format:

"http://www.example.com;foo=bar"

I believe the reported behavior is found in many versions and might even have been around a long time.


Actual results:

When entered into Firefox (or when a HTTP Location: redirect is followed) it will magically "fix" this URI by inserting a slash in front of the semicolon and then show that page's content.


Expected results:

Firefox should reject the URI since it isn't a legal one.

Chrome and curl don't support it, neither does many URI parsers such as the one in gmail.

This is important because sites will not inter-operate properly and the somewhat ironic part here is of course that I saw this reported on a live site out there which worked fine only with Firefox due to this.

In my view, RFC3986 section 3.2 supports my position.

I suspected bug #665706, but it seems I was mistaken.

(disclaimer: I am the primary author of curl and its URI parser logic)

Comment 1

[Boris Zbarsky [:bzbarsky]]

I can confirm the described behavior in Firefox 8 but not Firefox 9 betas or current trunk.

Bug 665706 was fixed in Firefox 9 (see the target milestone field there), so this may in fact be a duplicate of that bug.

Comment 2

[Julian Reschke]

Clarifying; Bug 665706 was about the historical special-casing of ";" in URIs.

Before FF9, ";" was parsed as delimiter, so 

  http://www.example.com;foo=bar

would parse into scheme "http", authority "www.example.com", an empty path and a parameter "foo=bar". Re-serializing would insert the missing "/".

With the bug fix, ";" isn't treated as delimiter anymore, so the parser should end up with a scheme of "http" and and authority of "www.example.com;foo=bar". How that is treated in other components I don't know.

Comment 3

[Harald]

The Bugfix from 665706 generates a kind of weakness in FF >= 9.

Our server provides documents in the form of filename.doc;jsessionid=$SOME_MAGIC_NUMBER. Don't know if the http://server stuff was already stripped off.
The <saveas> box pops up and the file can be saved with this filename including the session id. 
Directly starting the application is not possible because windows does not detect the filetype.

IE and FF8 work well.

Any ideas how to work around this. I don't want to downgrade.

Comment 4

[Boris Zbarsky [:bzbarsky]]

So is the issue that the saveas box used to offer "filename.doc" as the filename and now offers "filename.doc;jsessionid=$SOME_MAGIC_NUMBER"?

Sounds like this should be fixed in the filepicker or the code that brings it up. Could you file a bug on that, please?

Comment 5

[Harald]

Exactly, 

> Could you file a bug on that, please?
Done. 
https://bugzilla.mozilla.org/show_bug.cgi?id=732567

Comment 6

[Julian Reschke]

(In reply to Daniel Stenberg from comment #0)
> User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like
> Gecko) Chrome/15.0.874.121 Safari/535.2
> 
> Steps to reproduce:
> 
> Entered a malformed URI into the URL field of Firefox (Iceweasel 8.0-3+b1 on
> Debian to be specific, I don't know what Core/Networking version this
> corresponds to) using this format:
> 
> "http://www.example.com;foo=bar"
> 
> I believe the reported behavior is found in many versions and might even
> have been around a long time.
> 
> 
> Actual results:
> 
> When entered into Firefox (or when a HTTP Location: redirect is followed) it
> will magically "fix" this URI by inserting a slash in front of the semicolon
> and then show that page's content.
> 
> 
> Expected results:
> 
> Firefox should reject the URI since it isn't a legal one.
> 
> Chrome and curl don't support it, neither does many URI parsers such as the
> one in gmail.
> 
> This is important because sites will not inter-operate properly and the
> somewhat ironic part here is of course that I saw this reported on a live
> site out there which worked fine only with Firefox due to this.
> 
> In my view, RFC3986 section 3.2 supports my position.
> 
> I suspected bug #665706, but it seems I was mistaken.
> 
> (disclaimer: I am the primary author of curl and its URI parser logic)

Daniel,

I just tried and FF indeed displays an error message, probably since FF9 (Bug 665706).

Could you please re-check and then maybe close the bug?

Comment 7

[Daniel Stenberg [:bagder]]

Confirmed. This behavior is now fixed. Issue resolved.