IBM Watson bad request API error

[videoman614]

System

• OS name: Archlinux
• OS version: Kernel 6.9.2-arch1-1 (Wayland)
• Browser name: Firefox
• Browser version: 126.0.1

Extension

• Extension version: 2.0.1
• User input simulation: no
• Client app version: 0.3.0
• Client app installed successfully: yes

Bug description IBM Watson doesn't work with this error.

Was working perfectly in March when I tried it for the first time.

Logs

Browser:

Error: API response: 400, {
   "error": "could not convert string to float: 'u=4'",
   "code": 400,
   "code_description": "Bad Request"
}

[dessant]

Chrome 124 and Firefox 126 are now sending the Priority HTTP header with every request, which can break some websites and API endpoints.

The Priority header does not appear to be exposed in the declarativeNetRequest and the blocking webRequest extension APIs, and it is ignored when set during a fetch request, so extensions cannot remove the header before it is sent to the server.

This is possibly because the new header is still a work in progress in terms of specs and implementation.

https://github.com/whatwg/fetch/issues/1718

https://chromestatus.com/feature/5109106573049856

I could not find any changelog entry for the past few versions of Firefox about this new header: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases

However, I did find the network.http.priority_header.enabled about:config option, if you set it to false in Firefox and then restart the browser, The IBM Watson API should start working again.

[pmeenan]

The Priority HTTP header is defined in RFC 9218 and Safari and Firefox have always sent it for requests over HTTP/3. Chrome recently added it for HTTP/2 and HTTP/3 (previously only sent the priority frame).

At least in the case of Chrome, if the Priority header is set before it gets to the networking stack then the user-supplied value will be used.

[dessant]

@videoman614, version 3.1.0 uses some workarounds to send API calls that IBM's service can accept in the new browser versions, so it's no longer necessary to turn off network.http.priority_header.enabled in about:config, though the update is still under review on Firefox.

@pmeenan, it's unfortunate that this new header was implemented without taking into account the existence of the request filtering engine available to extensions, declarativeNetRequest and webRequest do not see the header because it is set by the browser after request filtering occurs, so extensions cannot remove it.

I hope your team at Google and @valenting's at Mozilla will find a way to remediate this oversight.

@valenting, it's also messed up that such a major change like introducing a new header for HTTP/2 requests isn't even mentioned in the Firefox 126 changelog for developers.

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/126

[valenting]

@dessant We have a bug working on a fix for this: 1900362 - Do not override the Priority header when set by the user

Note that before we added the Priority header to HTTP/2 requests, it was already being sent to servers, but it wasn't even visible to devtools - it was added in the HTTP/3 stack. So this isn't an entirely new bug.