Skip to content

Commit

Permalink
Discuss concrete CORS implementation.
Browse files Browse the repository at this point in the history
  • Loading branch information
RubenVerborgh committed Jul 18, 2019
1 parent 1578f44 commit 3727652
Showing 1 changed file with 31 additions and 3 deletions.
34 changes: 31 additions & 3 deletions main/resource-access.bs
Original file line number Diff line number Diff line change
Expand Up @@ -90,17 +90,45 @@ through the right HTTP header configuration.
### Required server-side implementation ### {#cors-server}

A [=data pod=] MUST implement the CORS protocol [[!FETCH]]
such that no request to it or response from it
is blocked by the browser.
such that, to the extent possible,
no request to it or response from it is blocked by the browser.
If the data pod wishes to block access to a resource,
this MUST NOT happen via CORS
but MUST instead be communicated to the Solid app in the browser
through HTTP status codes such as 401, 403, or 404 [[!RFC7231]].
Furthermore,
all response headers MUST be exposed to the Solid app.

Note: Since the CORS protocol is part of a Living Standard,
it should still be considered in evolution.
Changes to the CORS protocol might thus happen at any point,
which might necessitate changes to server implementations
to prevent undesired blocking.
for continued prevention of undesired blocking.
A [proposal](https://github.com/whatwg/fetch/issues/878) to mitigate this
has been suggested.

Concretely,
whenever a data pod receives an HTTP request
containing an `Origin` header [[!RFC6454]],
the server MUST respond with the appropriate `Access-Control-*` headers
as specified in the CORS protocol [[!FETCH]].
A data pod MUST also support the HTTP `OPTIONS` method [[!RFC7231]]
such that it can respond appropriately to CORS preflight requests.

Careful attention is warranted,
especially because of the many edge cases.
For instance,
data pods SHOULD enumerate all response headers under `Access-Control-Expose-Headers`
because there are cases (credentials mode set to `include`)
where using `*` as a value does not work.
As another example,
data pods SHOULD always explicitly list `Accept` under `Access-Control-Allow-Headers`.
This is recommended because,
despite `Accept` being safelisted,
values longer than 128 characters are blocked by default,
and the number of available RDF formats that Solid apps might use
could easily lead to longer value lengths.

Note: Under the current CORS protocol,
the correct HTTP response headers depend on the specifics of the request
and thus cannot be pre-generated.

0 comments on commit 3727652

Please sign in to comment.