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.

Sign up for GitHub

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

Jump to bottom

Navigate doesn't appear to handle redirects properly #461

Closed
jakearchibald opened this issue Jan 4, 2016 · 4 comments
Closed

Navigate doesn't appear to handle redirects properly #461

jakearchibald opened this issue Jan 4, 2016 · 4 comments
Assignees
@annevk
Labels
topic: navigation

Comments

@jakearchibald
Copy link
Contributor

https://html.spec.whatwg.org/multipage/browsers.html#navigate-redirect-step

I'm maybe missing something fundamental, but I don't see how the spec here deals with redirects. It doesn't look at the location header, or change the method from POST to GET etc etc.
@annevk
Copy link
Member

annevk commented Jan 4, 2016

Navigate still needs a lot of refactoring. For this particular issue we should:

  • Change Fetch to have an algorithm for creating a new request out of a request and a response that is a redirect.
  • Use that algorithm in HTML for navigate.

That alone would not address it cleanly though, since wherever navigate talks about a resource it can mean a history entry, a response, or a request, and none of that is really spelled out.

@annevk
Copy link
Member

annevk commented Jan 11, 2016

See also #314.

annevk added a commit to whatwg/fetch that referenced this issue Jan 11, 2016
@annevk
Introduce HTTP-redirect fetch
eb877f6 
See whatwg/html#461 for context. This allows
HTML to invoke a single algorithm to “handle redirects”, a concept it
mentions but does not actually define.

This changes the processing rules for redirect mode “manual”, but since
that is a rather new feature that should be fine.
@annevk annevk mentioned this issue Jan 11, 2016
Merged
annevk added a commit to whatwg/fetch that referenced this issue Jan 12, 2016
@annevk
Introduce HTTP-redirect fetch
9a267be 
See whatwg/html#461 for context. This allows
HTML to invoke a single algorithm to “handle redirects”, a concept it
mentions but does not actually define.

This changes the processing rules for redirect mode “manual”, but since
that is a rather new feature that should be fine.
annevk added a commit to whatwg/fetch that referenced this issue Feb 5, 2016
@annevk
Introduce HTTP-redirect fetch
3e501f2 
See whatwg/html#461 for context. This allows
HTML to invoke a single algorithm to “handle redirects”, a concept it
mentions but does not actually define.

This changes the processing rules for redirect mode “manual”, but since
that is a rather new feature that should be fine.
@jakearchibald jakearchibald mentioned this issue Apr 11, 2016
Closed
@annevk annevk mentioned this issue May 25, 2016
Closed
@annevk
Copy link
Member

annevk commented May 30, 2016

So the main reason navigate handles redirects specially is redirects to unknown schemes. Per Fetch those result in a network error, but they need to work for navigate supposedly.

If that is a thing it would probably be useful for Fetch to either abstract its Location header parsing or expose that as a property of a redirect response somehow.

This was referenced May 30, 2016
Closed
Closed
annevk added a commit that referenced this issue Jun 30, 2016
@annevk
Navigate: remove "gone async" and define redirect handling
37e45be 
Redirect handling had the following issues that are now fixed:

* /a navigating to /b which redirects to /a#test would not unload /a.
* Headers set on the initial request were not preserved.
* Redirects to javascript URLs would not result in an error.
  Fixes #314.
* Location header was not parsed, and HTTP method was not changed
  where needed. Fixes #461.

Another source of complexity was the "gone async" mechanism, which
was used for two steps that could just as easily be factored out and
had to be since they were run synchronously, but should not be.

Changing that fixes #1446 which discusses the issue around unknown
URL schemes in more detail.
annevk added a commit that referenced this issue Jun 30, 2016
@annevk
Navigate: remove "gone async" and define redirect handling
f8f1134 
Redirect handling had the following issues that are now fixed:

* /a navigating to /b which redirects to /a#test would not unload /a.
* Headers set on the initial request were not preserved.
* Redirects to javascript URLs would not result in an error.
  Fixes #314.
* Location header was not parsed, and HTTP method was not changed
  where needed. Fixes #461.

Another source of complexity was the "gone async" mechanism, which
was used for two steps that could just as easily be factored out and
had to be since they were run synchronously, but should not be.

Changing that fixes #1446 which discusses the issue around unknown
URL schemes in more detail.
@annevk
Copy link
Member

annevk commented Jun 30, 2016

#1476 attempts to fix this.

@annevk annevk closed this as completed in 8b630f5 Jul 4, 2016
alice pushed a commit to alice/html that referenced this issue Jan 8, 2019
@annevk
Navigate: remove "gone async" and define redirect handling
ae3135a 
Redirect handling had the following issues that are now fixed:

* /a navigating to /b which redirects to /a#test would not unload /a.
* Headers set on the initial request were not preserved.
* Redirects to javascript URLs would not result in an error.
  Fixes whatwg#314.
* Location header was not parsed, and HTTP method was not changed
  where needed. Fixes whatwg#461.

Another source of complexity was the "gone async" mechanism, which
was used for two steps that could just as easily be factored out and
had to be since they were run synchronously, but should not be.

Changing that fixes whatwg#1446 which discusses the issue around unknown
URL schemes in more detail.

multipart/x-mixed-replace no longer invokes the navigate algorithm 
halfway through, but instead invokes a dedicated algorithm.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@annevk annevk

Labels
topic: navigation
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jakearchibald @annevk