Closed Bug 1397646 Opened 7 years ago Closed 1 year ago

For HTTP/2 statusText (both Fetch and XMLHttpRequest) should always be the empty byte sequence

Categories

(Core :: DOM: Networking, enhancement, P3)

Product:
Core
Component:
DOM: Networking
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
118 Branch
Tracking Flags:
Tracking Status
firefox118 --- fixed

People

(Reporter: annevk, Assigned: twisniewski)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged])

Attachments

(1 file, 1 obsolete file)

Bug 1397646 - return empty statusText for HTTP2 fetches and XMLHttpRequests; r?kershaw
(deleted), text/x-phabricator-request
Details
See https://github.com/whatwg/fetch/issues/599. I don't have tests unfortunately as web-platform-tests doesn't support HTTP/2.
If we need to get it prioritized, please let us know.
Priority: -- → P3
Moving this to Networking as it seems more likely this is an issue with our underlying implementation.
Component: DOM → Networking
Summary: For HTTP/2 responseText (both Fetch and XMLHttpRequest) should always be the empty byte sequence → For HTTP/2 statusText (both Fetch and XMLHttpRequest) should always be the empty byte sequence
This is almost certainly because our h2 implementation is effectively an h1 translation layer, so there's very little outside necko that cares if a request is h2. To help with potential assumptions about a status phrase existing, when we translate responses from h2 into h1, we synthesize status phrases (see bug 950910 - also used for h1, so not something we want to get rid of entirely). We should evaluate whether we want to globally do away with status phrases for h2 (which I'm hesitant to do - being able to read the status phrases (in, say, dev tools) makes it easier for people to understand what happened with their request; could also have other fallout we're not anticipating) or if we just want to force an empty statusText in the DOM for fetch & xhr over h2. If we go with the latter (what I'm inclined towards), this would be more appropriate living in DOM. There, you can see if the connection is h2 (you should be able to use nsIHttpChannel.GetProtocolVersion to figure that out) and if so, just ignore any status phrase the http layer reports.
Component: Networking → DOM
Nicholas, I think bug 950910 should be reverted to some extent. From a protocol standpoint they don't exist for HTTP/2, so requiring each endpoint to mask them to avoid exposing them to web content seems rather risky. If tooling needs this, why can't we add them there? In HTTP/1 it's also optional and can basically be any string, so making something up (even if the default suggested phrase) seems somewhat incorrect.
Flags: needinfo?(hurley)
(In reply to Anne (:annevk) from comment #4) > Nicholas, I think bug 950910 should be reverted to some extent. From a > protocol standpoint they don't exist for HTTP/2, so requiring each endpoint > to mask them to avoid exposing them to web content seems rather risky. If > tooling needs this, why can't we add them there? > > In HTTP/1 it's also optional and can basically be any string, so making > something up (even if the default suggested phrase) seems somewhat incorrect. I still disagree. As you mention, for http/1 at least, the status phrase can be absolutely anything. In fact, for the better part of 20 years, if we didn't receive a status phrase, necko would just put one that says "OK" in place, regardless of the code. We made it nicer a few years back. In fact, we even synthesize status phrases for http/0.9, which doesn't even have a status *line*, let alone a phrase! So that leaves us with a few issues. (1) gecko has 20 years of expecting status phrases everywhere, and the chances of breaking someone expecting a status phrase that I haven't found is non-trivial (this goes double for the fact that http status lines are available to extensions, who may be depending on us providing a status phrase as we always have). (2) content-level consumers of the status phrase really shouldn't care what it is (since, as you note, it can be just about anything in h1, and there's no guarantee that any particular connection will be h2). (3) It remains the case that having explanatory status text available is very useful. To be honest, I'm not even sure the fetch or xhr specs should be enforcing *anything* about statusText, given its history and flexible nature. Given all that, if the DOM *really* wants to insist on statusText being the empty string for h2 connections, I think the DOM should enforce that. I don't see it being worth the technical risk of changing necko just to satisfy an attempt to be strict on something that has historically not been particularly strict.
Flags: needinfo?(hurley)
Flags: needinfo?(bzbarsky)
Flags: needinfo?(bzbarsky)
To be clear, it's not about insisting, it's about what's being standardized and being interoperable with other browsers. And this includes extensions, which share APIs and code with equivalent extensions for Chrome, Edge, and Safari. So by exposing something here we have the risk that code not anticipating that will end up failing in Firefox. And by not fixing it Networking we end up with an architecture that is a mismatch with standards and future expectations of any new API around this.
Flags: needinfo?(hurley)
And I'm arguing that perhaps we shouldn't be trying to standardize something that has no particularly standard format to begin with, nor can you a priori say that a particular resource will be coming over h2, so you can't just expect "hey, this connection will be h2, and therefore I shouldn't see a statusText". Yes, you can tell after the fact if something came over h2, but we *already* make changes to h2 responses (injecting headers, for example), so adding a status phrase isn't, like, totally out of the realm of sanity. Either way, I can tell that this conversation is likely to continue in circles. As such, I'll ni?mcmanus for a module owner's decision.
Flags: needinfo?(hurley) → needinfo?(mcmanus)
have you just considered taking status text out of the fetch specification? What does it add? If it adds something that isn't version specific, why wouldn't our approach be right? I actually think we're doing the right thing - it has a semantic but no literal value in h2. (in h1 it has both). We're reporting the semantic. any change here would need to consider the impact to devtools (which is no doubt solvable).
Flags: needinfo?(mcmanus)
If I had known (or someone had told me) it would be slowly removed from HTTP at the time we created Response I'd never have added it, though not sure if it matters much as exposed in XMLHttpRequest too. I suspect that removing it from both places is likely not web compatible and if we can't remove it from both it's not really worth the trouble removing it from either. I just had a look at devtools and I only found it reporting the status code, coupled with a link to MDN to learn more about the status code. Where does it report the status text?
Flags: needinfo?(mcmanus)
looks like its just under raw headers in devtools now.. I think the more info link is 'new' and welcome. There might be other places that consume it too..
Flags: needinfo?(mcmanus)
I'm confused. On the one hand the argument seems to be that this field is meaningless, but on the other hand there's a concern over breaking internal consumers. (It appears the concern over devtools was not valid.) If there's already concern over breaking internal consumers, why isn't it much bigger concern for external consumers, and doesn't that mean we should address this in a way that minimizes risk and aligns with other browsers?
External consumers already have to handle just about anything (empty string, meaningful text, a meaningless sequence of (printable?) bytes) in statusText. Internal consumers may, in fact, depend on us having something meaningful to display (or at the very least, that the status phrase isn't the empty string). This field, as pointed out multiple times previously, is in no way particularly "standard" anywhere (except on the wire in h2). I think there needs to be *very* strong evidence that standardizing this field will be a *large* benefit to external consumers before we should expend the standardization effort.
The effort is already expended as far as the APIs under consideration are concerned... This bug was filed as a result of that effort.

Anne, is a decision here something we should prioritize? Based on the discussion, I'm not sure if it would be worthwhile to start with just having XHRs and Fetch Responses return a blank statusText if their channel.GetProtocolVersion == "h2"?

Flags: needinfo?(annevk)

I think that's worthwhile doing. If we can do it at a lower-level that would be better, but not making it web-exposed seems like a win as it might become some kind of interoperability issue.

I suspect HTTP/3 and whatever comes after will also not expose this, so we might want to be forward-compatible with that in the check.

Flags: needinfo?(annevk)
Component: DOM → DOM: Core & HTML

@Honza, given Anne's point in comment 15, do you know which version string we'll end up returning from channel.GetProtocolVersion for http/3? "h3"? Or should I perhaps add a protocolSupportsStatusText method to channels instead for a forward-looking check?

Flags: needinfo?(odvarko)

Actually, maybe it would be simplest to just change the base HTTP channel's GetResponseStatusText method (which of course XHRs and Fetch both check) instead? Something like this:

 NS_IMETHODIMP
 HttpBaseChannel::GetResponseStatusText(nsACString& aValue) {
+  // http/2 should return an empty string
+  nsAutoCString version;
+  Unused << GetProtocolVersion(version);
+  if (version.Equals("h2")) {
+    aValue.Truncate();
+    return NS_OK;
+  }
+
   if (!mResponseHead) return NS_ERROR_NOT_AVAILABLE;
   mResponseHead->StatusText(aValue);
   return NS_OK;
 }

And also, since the web platform tests aren't ready for this yet, I'm wondering whether it would be alright to add to netwerk/test/unit/test_http2.js, or if we should have separate tests for xhr and fetch?

@baku: do you have an answer for comment #16?

Honza

Flags: needinfo?(odvarko) → needinfo?(amarchesini)
Component: DOM: Core & HTML → DOM: Networking

Valentin, do you know who to answer to comment 16?

Flags: needinfo?(amarchesini) → needinfo?(valentin.gosu)

(In reply to Thomas Wisniewski [:twisniewski] from comment #16)

[...] do you know which version string we'll end up returning from channel.GetProtocolVersion for http/3? "h3"?

I suspect it's going to be "h3". Dragana can confirm.

Or should I perhaps add a protocolSupportsStatusText method to channels instead for a forward-looking check?

That would probably be a nicer solution for this.

Whiteboard: [necko-triaged]

WPT supports H2 now and I've landed the relevant tests: https://github.com/web-platform-tests/wpt/pull/12490. There's no support for H3 on WPT so no H3 tests unfortunately.

Severity: normal → S3
Attached patch attempt.diff (obsolete) (deleted) — — Splinter Review

Revisiting this, I've written a patch which seems like it should work, but it only passes the XMLHttpRequest versions of the tests. The fetch ones are getting an empty string from the channel's GetProtocolVersion, rather than "h2", and I'm not familiar enough with the code to figure out why. For now I'll just attach a patch here in case someone else has any clues.

Hi Sunil, could you take a look at comment #23 and try to help Thomas?
Thanks.

Flags: needinfo?(smayya)

Hello Thomas,

We should be able to get the correct version if you use the HttpBaseChannel::GetProtocolVersion instead of the overriden method in HttpChannelChild.

The HttpChannelChild returns a member variable for the protocol version which gets populated only after OnStopRequest here. AFAIK, this is the reason for empty version value.
I am not sure why we need the GetProtocolVersion override function in HttpChannelChild.
I will check this further on Monday.

I think you can use this patch for unblocking your tests.

NS_IMETHODIMP
HttpChannelChild::GetProtocolVersion(nsACString& aProtocolVersion) {
+  if (mProtocolVersion.IsEmpty()) {
+    HttpBaseChannel::GetProtocolVersion(aProtocolVersion);
+    return NS_OK;
+  }
+
  aProtocolVersion = mProtocolVersion;
  return NS_OK;
}
Flags: needinfo?(smayya)

Thanks Sunil! That patch seems to have done the trick, so once we figure out the right way to fix that, we should be able to land this:
https://treeherder.mozilla.org/jobs?repo=try&revision=672b04c71c72d0775341335b552203a5e06c733a

Hello Thomas,
I discussed the issue with Kershaw.
We have the overridden HttpChannelChild::GetProtocolVersion because the function because the protocol version is more reliable than the one retrieved from HttpBaseChannel::GetProtocolVersion in base class. HttpChannelChild::GetProtocolVersion populates the protocol version received via IPC during the OnStopRequest. The version received via IPC is derived from the connection info object which is only available in the parent process.
The versions retrieved from connection info represents the actual protocol used and sometimes could differ from the version in the response head.

As the fetchDriver needs this info during OnStartRequest, we have decided to pass the version info via IPC during OnStartRequest instead of OnStopRequest. I will write a bug for this will try to release a patch soon (hopefully by next week).

Flags: needinfo?(twisniewski)
Depends on: 1844535

The fix mentioned in comment 27 has now landed, and a fresh try-run for the patch (without the work-around) seems green to me: https://treeherder.mozilla.org/jobs?repo=try&revision=505e4398203da4b7aba8c7718ea94986c5188345

So let's go for it.

Flags: needinfo?(twisniewski)
Attachment #9342965 - Attachment is obsolete: true
Assignee: nobody → twisniewski
Status: NEW → ASSIGNED
Attachment #9345678 - Attachment description: Bug 1397646 - return empty statusText for HTTP2 fetches and XMLHttpRequests; r?kershaw,kershaw → Bug 1397646 - return empty statusText for HTTP2 fetches and XMLHttpRequests; r?kershaw
Pushed by twisniewski@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/07b44dd04f0d return empty statusText for HTTP2 fetches and XMLHttpRequests; r=kershaw,necko-reviewers,sunil

Backed out for causing XHR related mochitest failures.

Flags: needinfo?(twisniewski)

Oh, there's an http2 mode in mochitests now...

It looks like I'll have to annotate that test as skipped for http2 mode, and add a second version which is skipped if not http2, with the right expectations. I'll try to get that done soon.

Flags: needinfo?(twisniewski)

This happened later and turned out to also be caused by this. Needinfo you again Thomas so you won't miss this when making the patch again.
failure log

[task 2023-07-31T23:07:32.482Z] 23:07:32     INFO - TEST-PASS | browser/components/resistfingerprinting/test/mochitest/test_bug1354633_media_error.html | Message should not be blank 
[task 2023-07-31T23:07:32.482Z] 23:07:32     INFO - decode_error.mp4: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - auto mozilla::SupportChecker::AddMediaFormatChecker(const TrackInfo &)::(anonymous class)::operator()() const: Decoder may not have the capability to handle the requested video format with YUV444 chroma subsampling.
[task 2023-07-31T23:07:32.482Z] 23:07:32     INFO - Buffered messages finished
[task 2023-07-31T23:07:32.482Z] 23:07:32     INFO - TEST-UNEXPECTED-FAIL | browser/components/resistfingerprinting/test/mochitest/test_bug1354633_media_error.html | Error message in allowlist: 404: Not Found - got "", expected "404: Not Found"
[task 2023-07-31T23:07:32.482Z] 23:07:32     INFO - SimpleTest.is@https://mochi.test:8888/tests/SimpleTest/SimpleTest.js:507:14
[task 2023-07-31T23:07:32.482Z] 23:07:32     INFO - testPromise/</video.onerror@https://mochi.test:8888/tests/browser/components/resistfingerprinting/test/mochitest/test_bug1354633_media_error.html:20:18
[task 2023-07-31T23:07:32.482Z] 23:07:32     INFO - EventHandlerNonNull*testPromise/<@https://mochi.test:8888/tests/browser/components/resistfingerprinting/test/mochitest/test_bug1354633_media_error.html:13:3
[task 2023-07-31T23:07:32.482Z] 23:07:32     INFO - testPromise@https://mochi.test:8888/tests/browser/components/resistfingerprinting/test/mochitest/test_bug1354633_media_error.html:9:61
[task 2023-07-31T23:07:32.482Z] 23:07:32     INFO - testBody@https://mochi.test:8888/tests/browser/components/resistfingerprinting/test/mochitest/test_bug1354633_media_error.html:35:9
[task 2023-07-31T23:07:32.482Z] 23:07:32     INFO - async*@https://mochi.test:8888/tests/browser/components/resistfingerprinting/test/mochitest/test_bug1354633_media_error.html:50:9
[task 2023-07-31T23:07:32.482Z] 23:07:32     INFO - async*@https://mochi.test:8888/tests/browser/components/resistfingerprinting/test/mochitest/test_bug1354633_media_error.html:48:10
[task 2023-07-31T23:07:32.484Z] 23:07:32     INFO - GECKO(1594) | [Child 1783, MediaSupervisor #1] WARNING: Error constructing decoders: file /builds/worker/checkouts/gecko/dom/media/MediaFormatReader.cpp:439
[task 2023-07-31T23:07:32.485Z] 23:07:32     INFO - GECKO(1594) | [Child 1783, MediaSupervisor #1] WARNING: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - auto mozilla::SupportChecker::AddMediaFormatChecker(const TrackInfo &)::(anonymous class)::operator()() const: Decoder may not have the capability to handle the requested video format with YUV444 chroma subsampling.: file /builds/worker/checkouts/gecko/dom/media/MediaFormatReader.cpp:1774
[task 2023-07-31T23:07:32.486Z] 23:07:32     INFO - GECKO(1594) | [Child 1783, MediaDecoderStateMachine #1] WARNING: Decoder=7f058252cc00 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - auto mozilla::SupportChecker::AddMediaFormatChecker(const TrackInfo &)::(anonymous class)::operator()() const: Decoder may not have the capability to handle the requested video format with YUV444 chroma subsampling.: file /builds/worker/checkouts/gecko/dom/media/MediaDecoderStateMachineBase.cpp:166
[task 2023-07-31T23:07:32.489Z] 23:07:32     INFO - GECKO(1594) | JavaScript warning: https://mochi.test:8888/tests/browser/components/resistfingerprinting/test/mochitest/test_bug1354633_media_error.html, line 14: This error message will be blank when privacy.resistFingerprinting = true.  If it is really necessary, please add it to the whitelist in MediaError::GetMessage: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - auto mozilla::SupportChecker::AddMediaFormatChecker(const TrackInfo &)::(anonymous class)::operator()() const: Decoder may not have the capability to handle the requested video format with YUV444 chroma subsampling.
[task 2023-07-31T23:07:32.490Z] 23:07:32     INFO - TEST-PASS | browser/components/resistfingerprinting/test/mochitest/test_bug1354633_media_error.html | Blank error message: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - auto mozilla::SupportChecker::AddMediaFormatChecker(const TrackInfo &)::(anonymous class)::operator()() const: Decoder may not have the capability to handle the requested video format with YUV444 chroma subsampling. 
[task 2023-07-31T23:07:32.490Z] 23:07:32     INFO - GECKO(1594) | MEMORY STAT | vsize 10778MB | residentFast 164MB | heapAllocated 17MB
[task 2023-07-31T23:07:32.493Z] 23:07:32     INFO - GECKO(1594) | [Child 1783, Main Thread] WARNING: DispatchEvent called on non-current inner window, dropping. Please check the window in the caller instead.: file /builds/worker/checkouts/gecko/dom/base/nsGlobalWindowInner.cpp:4195
[task 2023-07-31T23:07:32.494Z] 23:07:32     INFO - GECKO(1594) | [Child 1783, Main Thread] WARNING: DispatchEvent called on non-current inner window, dropping. Please check the window in the caller instead.: file /builds/worker/checkouts/gecko/dom/base/nsGlobalWindowInner.cpp:4195
[task 2023-07-31T23:07:32.497Z] 23:07:32     INFO - TEST-OK | browser/components/resistfingerprinting/test/mochitest/test_bug1354633_media_error.html | took 2712ms
[task 2023-07-31T23:07:32.576Z] 23:07:32     INFO - TEST-START | browser/components/resistfingerprinting/test/mochitest/test_bug1382499_touch_api.html
Flags: needinfo?(twisniewski)

Thanks! I'll investigate that as well.

Flags: needinfo?(twisniewski)

The second error is just as esoteric; MediaErrors will now end up with empty strings for the status text, which is not normally an issue. However, resist fingerprinting mode expects the error messages to include the default text, and so I would rather add the default 404-text for HTTP2 responses and keep the code otherwise the same, instead of allow-listing two values (one with the text and one with just the code) to keep the fingerprinting protections the same.

Pushed by twisniewski@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/675cf3cb3d33 return empty statusText for HTTP2 fetches and XMLHttpRequests; r=kershaw,necko-reviewers,sunil

Backed out for causing mochitest failures on test_fetch_basic_http.html.
So far, this is the only failed test.

[task 2023-08-07T04:24:32.766Z] 04:24:32     INFO - TEST-START | dom/tests/mochitest/fetch/test_fetch_basic_http.html
[task 2023-08-07T04:24:33.070Z] 04:24:33     INFO - GECKO(3759) | ### XPCOM_MEM_BLOAT_LOG defined -- logging bloat/leaks to /tmp/tmptydogoaf.mozrunner/runtests_leaks_tab_pid4048.log
[task 2023-08-07T04:24:33.135Z] 04:24:33     INFO - TEST-INFO | started process screentopng
[task 2023-08-07T04:24:33.416Z] 04:24:33     INFO - TEST-INFO | screentopng: exit 0
[task 2023-08-07T04:24:33.417Z] 04:24:33     INFO - Buffered messages logged at 04:24:33
[task 2023-08-07T04:24:33.417Z] 04:24:33     INFO - TEST-PASS | dom/tests/mochitest/fetch/test_fetch_basic_http.html | Response should not be an error for file_XHR_pass1.xml 
[task 2023-08-07T04:24:33.418Z] 04:24:33     INFO - TEST-PASS | dom/tests/mochitest/fetch/test_fetch_basic_http.html | Status should match expected for file_XHR_pass1.xml 
[task 2023-08-07T04:24:33.418Z] 04:24:33     INFO - Buffered messages finished
[task 2023-08-07T04:24:33.420Z] 04:24:33     INFO - TEST-UNEXPECTED-FAIL | dom/tests/mochitest/fetch/test_fetch_basic_http.html | Status text should match expected for file_XHR_pass1.xml - got "", expected "OK"
[task 2023-08-07T04:24:33.420Z] 04:24:33     INFO - SimpleTest.is@https://mochi.test:8888/tests/SimpleTest/SimpleTest.js:507:14
[task 2023-08-07T04:24:33.421Z] 04:24:33     INFO - testURL/</p<@https://mochi.test:8888/tests/dom/tests/mochitest/fetch/test_fetch_basic_http.js:18:9
[task 2023-08-07T04:24:33.421Z] 04:24:33     INFO - promise callback*testURL/<@https://mochi.test:8888/tests/dom/tests/mochitest/fetch/test_fetch_basic_http.js:12:36
[task 2023-08-07T04:24:33.422Z] 04:24:33     INFO - testURL@https://mochi.test:8888/tests/dom/tests/mochitest/fetch/test_fetch_basic_http.js:11:13
[task 2023-08-07T04:24:33.422Z] 04:24:33     INFO - promise callback*runTest@https://mochi.test:8888/tests/dom/tests/mochitest/fetch/test_fetch_basic_http.js:261:6
[task 2023-08-07T04:24:33.422Z] 04:24:33     INFO - windowTest/</scriptEl.onload@https://mochi.test:8888/tests/dom/tests/mochitest/fetch/fetch_test_framework.js:127:9
[task 2023-08-07T04:24:33.422Z] 04:24:33     INFO - EventHandlerNonNull*windowTest/<@https://mochi.test:8888/tests/dom/tests/mochitest/fetch/fetch_test_framework.js:126:7
[task 2023-08-07T04:24:33.422Z] 04:24:33     INFO - windowTest@https://mochi.test:8888/tests/dom/tests/mochitest/fetch/fetch_test_framework.js:123:12
[task 2023-08-07T04:24:33.423Z] 04:24:33     INFO - testScript/<@https://mochi.test:8888/tests/dom/tests/mochitest/fetch/fetch_test_framework.js:139:14
[task 2023-08-07T04:24:33.423Z] 04:24:33     INFO - promise callback*testScript@https://mochi.test:8888/tests/dom/tests/mochitest/fetch/fetch_test_framework.js:138:6
[task 2023-08-07T04:24:33.423Z] 04:24:33     INFO - @https://mochi.test:8888/tests/dom/tests/mochitest/fetch/test_fetch_basic_http.html:19:11
[task 2023-08-07T04:24:33.424Z] 04:24:33     INFO - TEST-PASS | dom/tests/mochitest/fetch/test_fetch_basic_http.html | Response url should match request for simple fetch for file_XHR_pass1.xml 
[task 2023-08-07T04:24:33.424Z] 04:24:33     INFO - TEST-PASS | dom/tests/mochitest/fetch/test_fetch_basic_http.html | Response should have content-type for file_XHR_pass1.xml 
[task 2023-08-07T04:24:33.424Z] 04:24:33     INFO - TEST-PASS | dom/tests/mochitest/fetch/test_fetch_basic_http.html | Response should not be an error for file_XHR_pass2.txt 
[task 2023-08-07T04:24:33.425Z] 04:24:33     INFO - TEST-PASS | dom/tests/mochitest/fetch/test_fetch_basic_http.html | Status should match expected for file_XHR_pass2.txt 
[task 2023-08-07T04:24:33.425Z] 04:24:33     INFO - Not taking screenshot here: see the one that was previously logged
[task 2023-08-07T04:24:33.426Z] 04:24:33     INFO - TEST-UNEXPECTED-FAIL | dom/tests/mochitest/fetch/test_fetch_basic_http.html | Status text should match expected for file_XHR_pass2.txt - got "", expected "OK"
[task 2023-08-07T04:24:33.426Z] 04:24:33     INFO - SimpleTest.is@https://mochi.test:8888/tests/SimpleTest/SimpleTest.js:507:14
[task 2023-08-07T04:24:33.427Z] 04:24:33     INFO - testURL/</p<@https://mochi.test:8888/tests/dom/tests/mochitest/fetch/test_fetch_basic_http.js:18:9
[task 2023-08-07T04:24:33.427Z] 04:24:33     INFO - promise callback*testURL/<@https://mochi.test:8888/tests/dom/tests/mochitest/fetch/test_fetch_basic_http.js:12:36
[task 2023-08-07T04:24:33.427Z] 04:24:33     INFO - testURL@https://mochi.test:8888/tests/dom/tests/mochitest/fetch/test_fetch_basic_http.js:11:13
[task 2023-08-07T04:24:33.427Z] 04:24:33     INFO - promise callback*runTest@https://mochi.test:8888/tests/dom/tests/mochitest/fetch/test_fetch_basic_http.js:261:6
[task 2023-08-07T04:24:33.427Z] 04:24:33     INFO - windowTest/</scriptEl.onload@https://mochi.test:8888/tests/dom/tests/mochitest/fetch/fetch_test_framework.js:127:9
[task 2023-08-07T04:24:33.428Z] 04:24:33     INFO - EventHandlerNonNull*windowTest/<@https://mochi.test:8888/tests/dom/tests/mochitest/fetch/fetch_test_framework.js:126:7
[task 2023-08-07T04:24:33.428Z] 04:24:33     INFO - windowTest@https://mochi.test:8888/tests/dom/tests/mochitest/fetch/fetch_test_framework.js:123:12
[task 2023-08-07T04:24:33.428Z] 04:24:33     INFO - testScript/<@https://mochi.test:8888/tests/dom/tests/mochitest/fetch/fetch_test_framework.js:139:14
[task 2023-08-07T04:24:33.428Z] 04:24:33     INFO - promise callback*testScript@https://mochi.test:8888/tests/dom/tests/mochitest/fetch/fetch_test_framework.js:138:6
[task 2023-08-07T04:24:33.428Z] 04:24:33     INFO - @https://mochi.test:8888/tests/dom/tests/mochitest/fetch/test_fetch_basic_http.html:19:11
[task 2023-08-07T04:24:33.429Z] 04:24:33     INFO - TEST-PASS | dom/tests/mochitest/fetch/test_fetch_basic_http.html | Response url should match request for simple fetch for file_XHR_pass2.txt
Flags: needinfo?(twisniewski)

Hmm. It looks like I've missed another test or two which need to be split up so that they run differently in h2 mode (dom/tests/mochitest/fetch/test_fetch_basic_http.html and dom/tests/mochitest/fetch/test_fetch_basic_http_sw_empty_reroute.html). I'll try again when I have some more time.

Pushed by twisniewski@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0698d69f4131 return empty statusText for HTTP2 fetches and XMLHttpRequests; r=kershaw,necko-reviewers,sunil
Blocks: fetch

https://hg.mozilla.org/mozilla-central/rev/0698d69f4131

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
status-firefox118: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 118 Branch
Flags: needinfo?(twisniewski)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: