1161288 - Support app:// origins on Fetch API

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Fernando Jiménez Moreno [:ferjm]]

I get "TypeError: NetworkError when attempting to fetch resource" when trying to cache a resource via cache.addAll() within the install event handler. The same code works if I install the sw from an https:// origin.

Comment 1

[Fernando Jiménez Moreno [:ferjm]]

Attachment: WIP

Comment 2

[Fernando Jiménez Moreno [:ferjm]]

Attachment: WIP

Comment 3

[Fernando Jiménez Moreno [:ferjm]]

Attachment: v1

Comment 4

[Fernando Jiménez Moreno [:ferjm]]

Attachment: v1

Sorry for the spam. I forgot to add one file.

Comment 5

[Fernando Jiménez Moreno [:ferjm]]

https://hg.mozilla.org/try/pushloghtml?changeset=8aec12bebccc

Comment 6

[Fernando Jiménez Moreno [:ferjm]]

Ugh https://treeherder.mozilla.org/#/jobs?repo=try&revision=8aec12bebccc

Comment 7

[Nikhil Marathe [:nsm] (No longer reading bugmail, please needinfo?)]

Comment on attachment 8602188 [details] [diff] [review]
v1

Review of attachment 8602188 [details] [diff] [review]:
-----------------------------------------------------------------

I didn't review the script security bit. Everything else looks good!

::: dom/fetch/FetchDriver.cpp
@@ +686,5 @@
>  
> +    // We simulate the http protocol for jar/app requests
> +    uint32_t responseStatus = 200;
> +    nsAutoCString statusText;
> +    statusText.AssignLiteral("OK");

Replace this...

@@ +691,2 @@
>  
> +    response = new InternalResponse(responseStatus, statusText);

... with NS_LITERAL_CSTRING("OK") here.

Comment 8

[Fernando Jiménez Moreno [:ferjm]]

Comment on attachment 8602188 [details] [diff] [review]
v1

Thank you Nikhil.

Bobby, could you take a look at the nsScriptSecurityManager change, please? Thanks!

Comment 9

[Andrea Marchesini [:baku]]

Comment on attachment 8602188 [details] [diff] [review]
v1

Review of attachment 8602188 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/fetch/FetchDriver.cpp
@@ +14,5 @@
>  #include "nsIHttpHeaderVisitor.h"
>  #include "nsIScriptSecurityManager.h"
>  #include "nsIThreadRetargetableRequest.h"
>  #include "nsIUploadChannel2.h"
> +#include "nsIJARChannel.h"

alphabetic order.

@@ +294,5 @@
>      return FailWithNetworkError();
>    }
>  
>    if (scheme.LowerCaseEqualsLiteral("file")) {
>    } else if (scheme.LowerCaseEqualsLiteral("http") ||

can you remove this empty if(scheme.LowerCaseEqualsLiteral("file")) ?

Comment 10

[Bobby Holley (:bholley)]

Comment on attachment 8602188 [details] [diff] [review]
v1

Review of attachment 8602188 [details] [diff] [review]:
-----------------------------------------------------------------

::: caps/nsScriptSecurityManager.cpp
@@ +756,5 @@
>                                   nsIProtocolHandler::URI_DANGEROUS_TO_LOAD);
> +
> +    // In order to be able to test packaged apps (app:// scheme) from
> +    // mochitests (http:// scheme) we need to ignore the scheme mismatch.
> +    if (!Preferences::GetBool("security.uri.allow_scheme_mismatch", false) &&

I'm not wild about this - this seems like an overly-broad hammer to apply here, and we're trying to make the URI loading permissions simpler rather than adding more special cases. Can you describe the use-case you're trying to solve in more detail?

Comment 11

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c997b5af752d

Comment 12

[Fernando Jiménez Moreno [:ferjm]]

Talked to Bobby on IRC and he suggested a change in the test that solved the issue and avoids making the change in the ScriptSecurityManager.

Comment 13

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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