Per spec: https://wicg.github.io/webpackage/loading.html#parsing-b1 step 3 says that response's HTTPS state "none" is treated as a parse failure.

By the way does the spec text mean that loading from localhost should also redirect to the fallbackurl as well?

I think currently we're using content::IsOriginSecure, whose definition is rather based on webappsec-secure-contexts's one and is different from 'https state'.

+jyasskin@chromium.org

The spec text does mean that, but it wasn't really my intent. The "HTTPS State" is set in https://fetch.spec.whatwg.org/#http-network-fetch: "If response was retrieved over HTTPS, set its HTTPS state to either "deprecated" or "modern"." I'd rather use the Secure Contexts definition (https://w3c.github.io/webappsec-secure-contexts/#secure-contexts), but that's currently only available on environment settings objects, not responses.

mkwst@, do you have any recommendation here? Is there something else that web packaging should say to allow loading from localhost and file:? Should the HTTPS State defined in Fetch be different for those?

1.  I would be perfectly happy (generally!) to block loading from `file:` and loopback. We added the carveouts to Secure Contexts because developers were very interested in having development environments, not because I think they're amazing and wonderful things to support in themselves. :)

2.  If you'd like to support `file:` and `http://localhost`, you could reference the "potentially trustworthy" concept from https://w3c.github.io/webappsec-secure-contexts/#is-url-trustworthy. Would that work for you?

>c#4

I'd like to keep file: url if possible, for peer-to-peer file transfer or MHTML replacement use-cases.

We're also very interested in having development environments. :)

I'll switch the spec to "is potentially trustworthy" on the response's URL. Note that this winds up differing from "Is an environment settings object contextually secure?" when the HTTPS state is "deprecated", which I hadn't noticed when writing the current web packaging restriction.

I've sent https://github.com/WICG/webpackage/pull/352, with a request against Secure Contexts at https://github.com/w3c/webappsec-secure-contexts/issues/63.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3d96b59e9ec0c40a9c05313331a3ccaff83902e3

commit 3d96b59e9ec0c40a9c05313331a3ccaff83902e3
Author: Kouhei Ueno <kouhei@chromium.org>
Date: Tue Dec 18 13:30:18 2018

SignedExchange: Redirect if served from a non secure origin

Before this CL, navigating to a sxg served over http triggered its download.
This CL aligns the implementation to the loading spec [1] so that it will trigger redirect to the sxg's fallback url.

[1] https://wicg.github.io/webpackage/loading.html#parsing-b1

Bug:  915576 
Change-Id: I3b5dcf31b5e3a6d7c2287bcd8b8c7ad693b9d7e0
Reviewed-on: https://chromium-review.googlesource.com/c/1379791
Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org>
Reviewed-by: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Commit-Queue: Kouhei Ueno <kouhei@chromium.org>
Cr-Commit-Position: refs/heads/master@{#617467}
[modify] https://crrev.com/3d96b59e9ec0c40a9c05313331a3ccaff83902e3/content/browser/web_package/signed_exchange_handler.cc
[modify] https://crrev.com/3d96b59e9ec0c40a9c05313331a3ccaff83902e3/content/browser/web_package/signed_exchange_handler.h
[modify] https://crrev.com/3d96b59e9ec0c40a9c05313331a3ccaff83902e3/content/browser/web_package/signed_exchange_handler_unittest.cc
[modify] https://crrev.com/3d96b59e9ec0c40a9c05313331a3ccaff83902e3/content/browser/web_package/signed_exchange_loader.cc
[modify] https://crrev.com/3d96b59e9ec0c40a9c05313331a3ccaff83902e3/third_party/blink/web_tests/external/wpt/signed-exchange/sxg-non-secure-origin.tentative.html