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.

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

Add more XMLHttpRequest overrideMimeType() tests #8449

Merged
merged 4 commits into from
Apr 17, 2018

Conversation

annevk
Copy link
Member

@annevk annevk commented Nov 27, 2017

@ghost
Copy link

ghost commented Nov 27, 2017

Build PASSED

Started: 2017-12-04 14:39:08
Finished: 2017-12-04 14:43:15

View more information about this build on:

@annevk
Copy link
Member Author

annevk commented Nov 28, 2017

This is ready for review now. This is what is remaining:

annevk added a commit to whatwg/xhr that referenced this pull request Dec 4, 2017
Reset override MIME type when open() is invoked.

Actually make overriding the charset parameter work (setting override MIME type to the "MIME type portion" (now essence) as done previously would always erase it.

Tests: web-platform-tests/wpt#8449.
@annevk annevk force-pushed the annevk/xhr-overridemimetype branch from 5768bb1 to bc47269 Compare April 10, 2018 12:18
annevk added a commit to whatwg/xhr that referenced this pull request Apr 10, 2018
Reset override MIME type when open() is invoked.

Actually make overriding the charset parameter work (setting override MIME type to the "MIME type portion" (now essence) as done previously would always erase it.

Tests: web-platform-tests/wpt#8449.
@annevk annevk force-pushed the annevk/xhr-overridemimetype branch from bc47269 to e7bc32b Compare April 10, 2018 16:27
@annevk
Copy link
Member Author

annevk commented Apr 11, 2018

This could use review now.

@annevk annevk requested a review from domenic April 11, 2018 13:28
Copy link
Member

@domenic domenic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with comments

@@ -6,60 +6,67 @@
<div id="log"></div>
<script>
async_test(t => {
const client = new XMLHttpRequest()
const client = new XMLHttpRequest();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is extraordinarily hard to review because almost every line has changed, but I guess only because of semicolons? Please split up the commits at least next time.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I figured it wouldn't be much of an issue given how GitHub highlights stuff.

client.open("GET", "resources/status.py?content=thisshouldnotmakeadifferencebutdoes");
client.responseType = "blob";
client.send();
}, "Use text/xml as fallback MIME type, 2");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand why the above two tests are in a file related to overrideMimeType()?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No good reason.

client.open("GET", "resources/status.py");
client.responseType = "blob";
client.overrideMimeType(type);
client.send();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: whitespace is off here

["text/html;", "text/html"],
["x/x;?=x;charset=y", "x/x;charset=y"],
["text/html;x=ÿ", "text/html;x=\"ÿ\""]
].forEach(([inputType, outputType], index) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like you could use the whole JSON file for the above two tests. (If the JSON files says a parse failure, application/octet-stream; otherwise use the output.) As I've argued previously, this helps ensure that the same parser is being used in all parts of the codebase.

annevk added a commit to whatwg/xhr that referenced this pull request Apr 16, 2018
Reset override MIME type when open() is invoked.

Actually make overriding the charset parameter work (setting override MIME type to the "MIME type portion" (now essence) as done previously would always erase it.

Tests: web-platform-tests/wpt#8449.
@annevk
Copy link
Member Author

annevk commented Apr 16, 2018

I've made the change of using the smaller JSON resource here (since it's networking it doesn't seem good to use all), but I need to verify whether some tests should be added to that JSON resource resource that I've removed here or whether coverage remained equivalent. I should probably also have another look at code point usage just in case.

@ghost
Copy link

ghost commented Apr 16, 2018

Build PASSED

Started: 2018-04-16 11:32:46
Finished: 2018-04-16 11:37:29

View more information about this build on:

@annevk annevk merged commit ae41496 into master Apr 17, 2018
@annevk annevk deleted the annevk/xhr-overridemimetype branch April 17, 2018 08:50
annevk added a commit to whatwg/xhr that referenced this pull request Apr 17, 2018
This makes a number of changes:

* Integrates with the new MIME Sniffing infrastructure.
* Reset override MIME type when open() is invoked.
* Actually make overriding the charset parameter work (setting override MIME type to the "MIME type portion" (now essence) as done previously would always erase it).
* Use "get an encoding" (previously undefined) to convert from a label to an encoding.

Tests: web-platform-tests/wpt#8449.

Fixes #157.
@thw0rted
Copy link

thw0rted commented Sep 27, 2018

Can I suggest a test here? I don't see any tests to confirm that the browser follows step 12 of the updated spec for open(). I just got bit by this behavior -- Edge respects the direction to reset the override MIME type while apparently all other modern browsers do not (!). So, it would be helpful to have a test for:

  • make XHR for a resource with MIME type type1
  • call overrideMimeType("type2")
  • call open
  • verify that response has MIME type type1 not type2.

ETA: if this merits a new issue, I'd be happy to open one.

ETA Again: just found #12404, please disregard.

@wisniewskit
Copy link
Contributor

@thworted, yeah, it turned out that resetting the MIME type wasn't web compatible (or at least that's how I read the outcome of the investigation in #12289).

@thw0rted
Copy link

The worst part is that to be truly compatible, everybody will have to treat open as though it resets the MIME type or risk breaking if somebody has one of the affected builds of Edge, and given the way corporate environments work, that could be an issue for years to come.

@annevk
Copy link
Member Author

annevk commented Sep 28, 2018

Web developers should probably fix their servers to not send broken MIME types and migrate to fetch(). 😊

@thw0rted
Copy link

The first thing that comes to mind is XHR against a peer resource in a file:/// origin. Of course, a local file won't have a stored MIME type, as such, and while the browser (or OS?) might make a best-effort based on file extension, you aren't likely to have another place to step in and assert that you know better.

Maybe that's not compelling enough? Still, overrideMimeType exists and consistent behavior is in everybody's best interest.

Bishwarupjee pushed a commit to Bishwarupjee/xhr that referenced this pull request Jan 31, 2024
This makes a number of changes:

* Integrates with the new MIME Sniffing infrastructure.
* Reset override MIME type when open() is invoked.
* Actually make overriding the charset parameter work (setting override MIME type to the "MIME type portion" (now essence) as done previously would always erase it).
* Use "get an encoding" (previously undefined) to convert from a label to an encoding.

Tests: web-platform-tests/wpt#8449.

Fixes #157.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants