1345094 - [e10s] Redirect to local file does not work

Status: RESOLVED FIXED

(Core :: Networking: File, defect)

Description

[winflip]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

1. Disable all extensions.
2. Make sure the prefs are set up to allow local file links to your site
3. Have your site do a 302 redirect to your local file (file:///c:/foobar )

I have made a quick test site with instructions here for you to reproduce the issue: http://skyqueen.cc/testfiles.html


Actual results:

Corrupted Content Error
The site at foobar has experienced a network protocol violation that cannot be repaired.

The page you are trying to view cannot be shown because an error in the data transmission was detected. 
Please contact the website owners to inform them of this problem.


Expected results:

Same behaviour as a direct link to my local file; it displays or offers to download the local file.

Steps to workaround: install some type of extension. I have not figured out why some fix this issue and others don't. A very simple one is https://addons.mozilla.org/en-US/firefox/addon/clear-cache-button/ Merely installing this makes the issue go away.

Comment 1

[Loic]

That sounds like a duplicate of bug 1303727. Could you test with e10s disabled.

Comment 2

[winflip]

Confirmed that bug does not appear with e10s disabled, but it does not seem like a duplicate, because the bug still exists when tested in firefox 53.0a2 (2017-03-06) (32-bit) it is still there while  bug 1303727 is considered fixed in that version.

Comment 3

[Bob Owen (:bobowen)]

The same thing happens with the sandbox turned off, so I don't think this is a sandboxing issue.
I'm guessing this affects all platforms using e10s.

Given that normal redirects are working, this is probably a CAPS issue with e10s.

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

I'm planning to look more at this tomorrow, but my first thought is that this is related to the file process we implemented earlier (in order to enable the sandbox but not part of the sandbox). Bob, do you have any thoughts here?

Comment 5

[Bob Owen (:bobowen)]

(In reply to Blake Kaplan (:mrbkap) from comment #4)
> I'm planning to look more at this tomorrow, but my first thought is that
> this is related to the file process we implemented earlier (in order to
> enable the sandbox but not part of the sandbox). Bob, do you have any
> thoughts here?

This happens in release (and back as far as 45 although the behaviour changes slightly).
The file content process is only preffed on in Nightly and the changes didn't land until Fx53, so it seems it is just an e10s/CAPS issue.
I'd look into it further myself, but I'm pretty swamped at the moment, sorry.

Comment 6

[Bob Owen (:bobowen)]

(In reply to Bob Owen (:bobowen) from comment #5)

> This happens in release (and back as far as 45 although the behaviour
> changes slightly).

Just to be clear ... I should have said "as far as at least 45", I didn't check further back.

Comment 7

[Blake Kaplan (:mrbkap) (inactive)]

Sorry, yeah. This just never worked in e10s. The first obvious problem is that nsFileChannel doesn't implement nsIChildChannel (see also bug 1058551 which made redirects to data URIs work correctly). So, fixing this bug will involve, at the very least, fixing that problem. After that's fixed, I am curious whether the existing redirect code is robust enough to handle the redirect to the file process.

I don't have time to work on this myself. Jason, is there anyone on the necko team that has the cycles to look into this?

Comment 8

[u408661]

Attachment: Bug 1345094 - make http redirects to file:// uris work under e10s.

Review commit: https://reviewboard.mozilla.org/r/130088/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/130088/

Comment 9

[u408661]

This patch is almost entirely shamelessly stolen from the one in bug 1058551. It's also, fortunately, all we need.

Comment 10

[Honza Bambas (:mayhemer)]

Comment on attachment 8858117 [details]
Bug 1345094 - make http redirects to file:// uris work under e10s.

https://reviewboard.mozilla.org/r/130088/#review132984

::: netwerk/ipc/PFileChannel.ipdl:14
(Diff revision 1)
> +include URIParams;
> +
> +namespace mozilla {
> +namespace net {
> +
> +async protocol PFileChannel

please write comment what this is used for, every new interface or class has to have it.

::: netwerk/protocol/file/nsFileProtocolHandler.cpp:200
(Diff revision 1)
> +        chan = new mozilla::net::FileChannelChild(uri);
> +    } else {
> +        chan = new nsFileChannel(uri);
> +    }
>      if (!chan)
>          return NS_ERROR_OUT_OF_MEMORY;

when you are here, maybe remove the nonnull check?

Comment 11

[u408661]

Comment on attachment 8858117 [details]
Bug 1345094 - make http redirects to file:// uris work under e10s.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/130088/diff/1-2/

Comment 12

[u408661]

Comment on attachment 8858117 [details]
Bug 1345094 - make http redirects to file:// uris work under e10s.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/130088/diff/2-3/

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a3953fb9958d
make http redirects to file:// uris work under e10s. r=mayhemer

Comment 14

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/a3953fb9958d