Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Determine HTTP to HTTPS upgrade mechanism #27

Open
kjetilk opened this issue Aug 7, 2019 · 3 comments
Open

Determine HTTP to HTTPS upgrade mechanism #27

kjetilk opened this issue Aug 7, 2019 · 3 comments

Comments

@kjetilk
Copy link
Member

kjetilk commented Aug 7, 2019

Discussed briefly in #26 , there are several upgrade mechanisms from HTTP to HTTPS. We currently suggest 301 but it doesn't seem very settled what the semantics of 301 in relation to RDF, even though it has been discussed for a long time. It was raised in the TAG but doesn't seem to have a conclusion.

There's also RFC2817.

@acoburn
Copy link
Member

acoburn commented Aug 7, 2019

Somewhat orthogonal to the 3xx response code discussion, but perhaps we should also recommend the use of the Strict-Transport-Security header, defined in RFC 6797.

@elf-pavlik
Copy link
Member

Could you possibly define the problem a little bit more? I thought Solid will require HTTPS, I think OAuth2 also requires it.

@RubenVerborgh
Copy link
Contributor

I thought Solid will require HTTPS

It's a SHOULD. (There are cases, such as testing and behind a reverse proxy, where you want the pod itself to run over HTTP.)

But even when HTTPS is required/used, we still need to be able to react to regular HTTP requests, namely by switching them to HTTPS. This issue specifies how.

@csarven csarven added this to the March 19th milestone Oct 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants