979822 - Unexpected behaviour with mailto URI in Location header

Status: NEW

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

Description

[Lars Wiegman]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.117 Safari/537.36

Steps to reproduce:

1. I setup a webserver with the following two responses:

	$ curl http://example.com/	
	<html><body><a href="/mailto/joe">email joe</a></body></html>

	$ curl -i -X GET http://example.com/mailto/joe
	HTTP/1.0 303 See Other
	Location: mailto:[e-mail]
	Content-Length: 0
	Server: Werkzeug/0.9.4 Python/2.7.5
	Date: Wed, 05 Mar 2014 09:19:05 GMT

2. And click the link "email joe" to go to http://example.com/mailto/joe

When I clicked the link "email joe" my email application opens with a new email, which is good, but Firefox renders the 303 response and I'm left with a blank page.


Actual results:

Firefox renders the 303 response and I'm left with a blank page.


Expected results:

Firefox should not render the response and leave me with the original page.

Comment 1

[Lars Wiegman]

Both Chrome and Safari have expected results.

Comment 2

[Boris Zbarsky [:bzbarsky]]

It's not clear where the right place to handle this is, actually.  Why exactly is HTTP handing back a successful load here at all?  Or is it not?  If you send an actual response body with the 303, is that rendered?

Comment 3

[Lars Wiegman]

In Firefox the body response is rendered, in Safari and Chrome it is not.

When I add the following body response to the 303, Firefox will not only show the text "This should not be rendered" but fetch and parse the included stylesheet:

    $ curl -i http://example.com/mailto/joe
    HTTP/1.0 303 See Other
    Location: mailto:[e-mail]
    Content-Type: text/html; charset=utf-8
    Content-Length: 27
    Server: Werkzeug/0.9.4 Python/2.7.5
    Date: Thu, 20 Mar 2014 07:47:20 GMT

    <html><header><link rel="stylesheet" href="/style.css"></header><body><p>This should not be rendered</p></body></html>

I've tried other schemes in the Location header, like tel or itms, and they result in the same behaviour.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Yeah, that's an HTTP issue, then.  It shouldn't be falling through to passing the response body to the consumer in this case.

Comment 5

[Patrick McManus [:mcmanus]]

nick agreed to triage it

Comment 6

[u408661]

So this is pretty easy to patch over by forcing doNotRender to true for a mailto: redirect in nsHttpChannel::ContinueProcessResponse. However, it seems nasty to keep a list of blacklisted schemes, especially when external handlers can be added willy-nilly for schemes we don't know about. We could consider only whitelisting a few well-known schemes (http, https, ftp, file, probably one or two others I'm missing right now) and forcing doNotRender on all others.

Patrick, thoughts?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Would just adding NS_ERROR_NO_CONTENT to the list in DoNotRender3xxBody() not do the right thing?  That's what you should get for any protocol we hand off to the OS.

Comment 8

[u408661]

Thanks, Boris, that certainly satisfies my test case. Let me throw it at try and see if it breaks anything :)

Comment 9

[u408661]

Quick update - the try build has an ASAN make check failure that I (so far) can't make heads or tails of.

Comment 10

[u408661]

For my own reference (ie, before I lose the link) here's the try push with ASAN issues https://tbpl.mozilla.org/?tree=Try&rev=b4d211f5b81b

Comment 11

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258