Perform client-side redirect for /resolve #63
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This changes the behavior of resolving a permalink. Before, the public-api would send a 302 redirect to the browser, which would then follow that, eventually returning a 200 with a JSON payload of the resource (if found.) However, this was a problem for Safari 7+ (though I can't find a documented bug for it.) Safari was not transparently following the redirect on the simple CORS request. The reason is unclear; the origin of the redirected-to host is the same as the original request host, and it's a simple request (GET), with no additional headers that would trigger the preflight[1]. As if to support that this is a bug, Chrome and Firefox both do _not_ perform a preflight request before following the redirect. Since this is difficult to work around on the user agent itself, we'll have to use an out provided by the api and map the 302 code to a 200. We still get the redirect location in the JSON payload, so we can use that (and in fact, we already had support for this.) Performing the 'redirect' client-side causes the request to be made using a simple CORS request, as it should be done. [1]: https://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0
Contributor
Author
|
Published as |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This changes the behavior of resolving a permalink. Before, the
public-api would send a 302 redirect to the browser, which would then
follow that, eventually returning a 200 with a JSON payload of the
resource (if found.)
However, this was a problem for Safari 7+ (though I can't find a
documented bug for it.) Safari was not transparently following the
redirect on the simple CORS request. The reason is unclear; the origin
of the redirected-to host is the same as the original request host, and
it's a simple request (GET), with no additional headers that would
trigger the preflight1. As if to support that this is a bug, Chrome and
Firefox both do not perform a preflight request before following the
redirect.
Since this is difficult to work around on the user agent itself, we'll
have to use an out provided by the api and map the 302 code to a 200.
We still get the redirect location in the JSON payload, so we can use
that (and in fact, we already had support for this.)
Performing the 'redirect' client-side causes the request to be made
using a simple CORS request, as it should be done.
Fixes #27