XMLHttpRequest: response header value containing 0x00 #10424
Conversation
As discussed in whatwg/xhr#165 these should turn the response into a network error.
wpt-pr-bot
requested review from
caitp,
emilio,
hallvors,
ibelem,
jdm,
jungkees,
kangxu,
Manishearth,
mathiasbynens,
ronkorving and
wisniewskit
|
(Note that various cors/ tests use 0x00 in header values too, but those already expect a network error due to the nature of CORS.) |
xhr/headers-normalize-response.htm
Outdated
| matchHeaderValue(" "); | ||
| matchHeaderValue("\t"); | ||
| matchHeaderValue(""); | ||
|
|
||
| promise_test(t => { | ||
| return promise_rejects(t, new TypeError(), fetch("resources/parse-headers.py?my-custom-header="+encodeURIComponent("x\0x"))); | ||
| }, "Ensure fetch() rejects too") |
There was a problem hiding this comment.
This seems pretty out of place here; another separate file would be much better, in case people are testing fetch() and XHR in isolation.
There was a problem hiding this comment.
Because they're working on their fetch() or XHR implementation?
There was a problem hiding this comment.
You need to support both and they both need to fail in the same way due to both operating on the same low-level primitive.
There was a problem hiding this comment.
(And it's not like both are tested in the same test so it'd be easy to ignore some results.)
There was a problem hiding this comment.
(I actually think we might want to merge these directories at some point due to the worry of missing test coverage in either API.)
There was a problem hiding this comment.
I'm still not comfortable testing fetch in the XHR directory, sorry. It makes maintainers lives harder when they don't know where a given API's tests are.
There was a problem hiding this comment.
That's already the case though for many cross-purpose tests. I guess we could move this into the http/ directory...
wpt-pr-bot
requested review from
domfarolino,
mnot,
youennf and
yutakahirano
and removed request for
hallvors,
ronkorving and
kangxu
|
I moved it to a separate file for now. I think we already have this cross-dependency allowed elsewhere, but I want to get this landed. |
Tests to complement those written in #10424.
Tests to complement those written in #10424.
Automatic update from web-platform-tests HTTP: 0x00 in a header value Tests to complement those written in web-platform-tests/wpt#10424. -- wpt-commits: 38ecde806a5f1710d9e5beba700cef7352f7570e wpt-pr: 21019
Automatic update from web-platform-tests HTTP: 0x00 in a header value Tests to complement those written in web-platform-tests/wpt#10424. -- wpt-commits: 38ecde806a5f1710d9e5beba700cef7352f7570e wpt-pr: 21019
Automatic update from web-platform-tests HTTP: 0x00 in a header value Tests to complement those written in web-platform-tests/wpt#10424. -- wpt-commits: 38ecde806a5f1710d9e5beba700cef7352f7570e wpt-pr: 21019 UltraBlame original commit: 2df4f38122005c353cf34c665c293fcb975fbdb7
Automatic update from web-platform-tests HTTP: 0x00 in a header value Tests to complement those written in web-platform-tests/wpt#10424. -- wpt-commits: 38ecde806a5f1710d9e5beba700cef7352f7570e wpt-pr: 21019 UltraBlame original commit: 2df4f38122005c353cf34c665c293fcb975fbdb7
Automatic update from web-platform-tests HTTP: 0x00 in a header value Tests to complement those written in web-platform-tests/wpt#10424. -- wpt-commits: 38ecde806a5f1710d9e5beba700cef7352f7570e wpt-pr: 21019 UltraBlame original commit: 2df4f38122005c353cf34c665c293fcb975fbdb7
As discussed in whatwg/xhr#165 these should turn the response into a network error.