-
Notifications
You must be signed in to change notification settings - Fork 139
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
"Let pointer be a pointer to first code point in..." #373
Comments
Thanks but I'm still not sure what the spec is saying. Let's run the basic URL parser where After step 1, After step 10. "Let In step 11. we enter the state machine at "scheme start state". Is that correct as-written, and as-intended? |
… empty value. Blink was failing a DCHECK when it expected a redirect to be taken because the request mode was 'follow' and the response had a redirect status code and Location header. However, Chrome's //net considers a Location header with an empty value to be the same as no Location header at all. See the comments on bug 810288 about net::HttpResponseHeaders::IsRedirect(). WPT tests are added. The spec is unclear (whatwg/url#373) but seems to either say to fail with network error or enter a loop of self-redirects that will eventually hit the redirect limit and fail with network error. Chrome currently fails this test because it treats the Location as as non-existent, i.e., not a redirect response. Bug: 810288,707185 Change-Id: Iaca93976aaa697380b1542ab45d63c318f5050b0
… empty value. Blink was failing a DCHECK when it expected a redirect to be taken because the request mode was 'follow' and the response had a redirect status code and Location header. However, Chrome's //net considers a Location header with an empty value to be the same as no Location header at all. See the comments on bug 810288 about net::HttpResponseHeaders::IsRedirect(). WPT tests are added. The spec is unclear (whatwg/url#373) but seems to either say to fail with network error or enter a loop of self-redirects that will eventually hit the redirect limit and fail with network error. Chrome currently fails this test because it treats the Location as as non-existent, i.e., not a redirect response. Bug: 810288,707185 Change-Id: Iaca93976aaa697380b1542ab45d63c318f5050b0 Reviewed-on: https://chromium-review.googlesource.com/910753 Reviewed-by: Yutaka Hirano <[email protected]> Reviewed-by: Tsuyoshi Horo <[email protected]> Commit-Queue: Matt Falkenhagen <[email protected]> Cr-Commit-Position: refs/heads/master@{#536644}
… empty value. Blink was failing a DCHECK when it expected a redirect to be taken because the request mode was 'follow' and the response had a redirect status code and Location header. However, Chrome's //net considers a Location header with an empty value to be the same as no Location header at all. See the comments on bug 810288 about net::HttpResponseHeaders::IsRedirect(). WPT tests are added. The spec is unclear (whatwg/url#373) but seems to either say to fail with network error or enter a loop of self-redirects that will eventually hit the redirect limit and fail with network error. Chrome currently fails this test because it treats the Location as as non-existent, i.e., not a redirect response. Bug: 810288,707185 Change-Id: Iaca93976aaa697380b1542ab45d63c318f5050b0 Reviewed-on: https://chromium-review.googlesource.com/910753 Reviewed-by: Yutaka Hirano <[email protected]> Reviewed-by: Tsuyoshi Horo <[email protected]> Commit-Queue: Matt Falkenhagen <[email protected]> Cr-Commit-Position: refs/heads/master@{#536644}
… empty value. Blink was failing a DCHECK when it expected a redirect to be taken because the request mode was 'follow' and the response had a redirect status code and Location header. However, Chrome's //net considers a Location header with an empty value to be the same as no Location header at all. See the comments on bug 810288 about net::HttpResponseHeaders::IsRedirect(). WPT tests are added. The spec is unclear (whatwg/url#373) but seems to either say to fail with network error or enter a loop of self-redirects that will eventually hit the redirect limit and fail with network error. Chrome currently fails this test because it treats the Location as as non-existent, i.e., not a redirect response. Bug: 810288,707185 Change-Id: Iaca93976aaa697380b1542ab45d63c318f5050b0 Reviewed-on: https://chromium-review.googlesource.com/910753 Reviewed-by: Yutaka Hirano <[email protected]> Reviewed-by: Tsuyoshi Horo <[email protected]> Commit-Queue: Matt Falkenhagen <[email protected]> Cr-Commit-Position: refs/heads/master@{#536644}
No, that seems like a bug. 😟 This should basically return the base URL except for the fragment. |
I was never satisfied with the resolution to #343, as I didn't think it implemented what I wrote in #308, which is what I used in my Perl implementation. I haven't taken the time to confirm whether this issue revolves around those differences, but I figured I'd bring it up again for the sake of discussion. |
… with a Location header with empty value., a=testonly Automatic update from web-platform-testsFetch API: Don't DCHECK on a 302 response with a Location header with empty value. Blink was failing a DCHECK when it expected a redirect to be taken because the request mode was 'follow' and the response had a redirect status code and Location header. However, Chrome's //net considers a Location header with an empty value to be the same as no Location header at all. See the comments on bug 810288 about net::HttpResponseHeaders::IsRedirect(). WPT tests are added. The spec is unclear (whatwg/url#373) but seems to either say to fail with network error or enter a loop of self-redirects that will eventually hit the redirect limit and fail with network error. Chrome currently fails this test because it treats the Location as as non-existent, i.e., not a redirect response. Bug: 810288,707185 Change-Id: Iaca93976aaa697380b1542ab45d63c318f5050b0 Reviewed-on: https://chromium-review.googlesource.com/910753 Reviewed-by: Yutaka Hirano <[email protected]> Reviewed-by: Tsuyoshi Horo <[email protected]> Commit-Queue: Matt Falkenhagen <[email protected]> Cr-Commit-Position: refs/heads/master@{#536644} wpt-commits: e75788501733a0801eec374c19f8cdfbccd9c09d wpt-pr: 9453 wpt-commits: e75788501733a0801eec374c19f8cdfbccd9c09d wpt-pr: 9453
Step 11 in specification:
From @mattto's #373 (comment):
The order of (1) and (2) operations here is different than in the spec, so result is incorrect. If follow specification, then after (2) operation we enter the "no scheme state":
Then we enter the "relative state", and
Now the pointer isn't decreased, so it points to EOF and the state machine is done after (1) operation. The result is as specified in @annevk's #373 (comment). |
Aah right. That always annoyed me about how this state machine is written. If we can rewrite it somehow to be more basic that'd be good. |
… with a Location header with empty value., a=testonly Automatic update from web-platform-testsFetch API: Don't DCHECK on a 302 response with a Location header with empty value. Blink was failing a DCHECK when it expected a redirect to be taken because the request mode was 'follow' and the response had a redirect status code and Location header. However, Chrome's //net considers a Location header with an empty value to be the same as no Location header at all. See the comments on bug 810288 about net::HttpResponseHeaders::IsRedirect(). WPT tests are added. The spec is unclear (whatwg/url#373) but seems to either say to fail with network error or enter a loop of self-redirects that will eventually hit the redirect limit and fail with network error. Chrome currently fails this test because it treats the Location as as non-existent, i.e., not a redirect response. Bug: 810288,707185 Change-Id: Iaca93976aaa697380b1542ab45d63c318f5050b0 Reviewed-on: https://chromium-review.googlesource.com/910753 Reviewed-by: Yutaka Hirano <yhiranochromium.org> Reviewed-by: Tsuyoshi Horo <horochromium.org> Commit-Queue: Matt Falkenhagen <falkenchromium.org> Cr-Commit-Position: refs/heads/master{#536644} wpt-commits: e75788501733a0801eec374c19f8cdfbccd9c09d wpt-pr: 9453 wpt-commits: e75788501733a0801eec374c19f8cdfbccd9c09d wpt-pr: 9453 UltraBlame original commit: 794c66f8f16ec6e3439a4485a75bf80492609514
… with a Location header with empty value., a=testonly Automatic update from web-platform-testsFetch API: Don't DCHECK on a 302 response with a Location header with empty value. Blink was failing a DCHECK when it expected a redirect to be taken because the request mode was 'follow' and the response had a redirect status code and Location header. However, Chrome's //net considers a Location header with an empty value to be the same as no Location header at all. See the comments on bug 810288 about net::HttpResponseHeaders::IsRedirect(). WPT tests are added. The spec is unclear (whatwg/url#373) but seems to either say to fail with network error or enter a loop of self-redirects that will eventually hit the redirect limit and fail with network error. Chrome currently fails this test because it treats the Location as as non-existent, i.e., not a redirect response. Bug: 810288,707185 Change-Id: Iaca93976aaa697380b1542ab45d63c318f5050b0 Reviewed-on: https://chromium-review.googlesource.com/910753 Reviewed-by: Yutaka Hirano <yhiranochromium.org> Reviewed-by: Tsuyoshi Horo <horochromium.org> Commit-Queue: Matt Falkenhagen <falkenchromium.org> Cr-Commit-Position: refs/heads/master{#536644} wpt-commits: e75788501733a0801eec374c19f8cdfbccd9c09d wpt-pr: 9453 wpt-commits: e75788501733a0801eec374c19f8cdfbccd9c09d wpt-pr: 9453 UltraBlame original commit: 794c66f8f16ec6e3439a4485a75bf80492609514
… with a Location header with empty value., a=testonly Automatic update from web-platform-testsFetch API: Don't DCHECK on a 302 response with a Location header with empty value. Blink was failing a DCHECK when it expected a redirect to be taken because the request mode was 'follow' and the response had a redirect status code and Location header. However, Chrome's //net considers a Location header with an empty value to be the same as no Location header at all. See the comments on bug 810288 about net::HttpResponseHeaders::IsRedirect(). WPT tests are added. The spec is unclear (whatwg/url#373) but seems to either say to fail with network error or enter a loop of self-redirects that will eventually hit the redirect limit and fail with network error. Chrome currently fails this test because it treats the Location as as non-existent, i.e., not a redirect response. Bug: 810288,707185 Change-Id: Iaca93976aaa697380b1542ab45d63c318f5050b0 Reviewed-on: https://chromium-review.googlesource.com/910753 Reviewed-by: Yutaka Hirano <yhiranochromium.org> Reviewed-by: Tsuyoshi Horo <horochromium.org> Commit-Queue: Matt Falkenhagen <falkenchromium.org> Cr-Commit-Position: refs/heads/master{#536644} wpt-commits: e75788501733a0801eec374c19f8cdfbccd9c09d wpt-pr: 9453 wpt-commits: e75788501733a0801eec374c19f8cdfbccd9c09d wpt-pr: 9453 UltraBlame original commit: 794c66f8f16ec6e3439a4485a75bf80492609514
Hi all,
To me we are at EOF after the 1st run since there is no stream per say as there is no content. Quick info from the spec
So I am puzzled as to how it is possible to enter the "relative state" ? |
I think it is indeed somewhat broken, but if we assume that we start out by pointer pointing at EOF (it's the empty string after all), it is then decreased by 1. Unclear what it now points at, but let's say not EOF so we continue and increase it by 1, at which point it again points to EOF but we're doing another run at least. But we should rewrite this in terms of Infra, possibly using https://infra.spec.whatwg.org/#collect-a-sequence-of-code-points. |
This makes the following changes: * Makes it clear pointer can be negative. * Uses 1 rather than one as the newish style. * Uses ordered lists for steps inside all states. * Clones paths rather than using an undefined copy operation. * Addresses a number of editorial nits. Closes #373 and closes #480.
https://url.spec.whatwg.org/commit-snapshots/5fc4c4c17f3077beda5e3647df73f4b1b0ba7084/#url-parsing
What happens if input is the empty string? See some confusion in whatwg/fetch#669
The text was updated successfully, but these errors were encountered: