Skip to content

Clarify that errorThrown and statusText will be empty strings in HTTP/2 #1146

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

Merged
merged 2 commits into from
Oct 5, 2019
Merged

Clarify that errorThrown and statusText will be empty strings in HTTP/2 #1146

merged 2 commits into from
Oct 5, 2019

Conversation

vkrol
Copy link
Contributor

@vkrol vkrol commented Aug 31, 2019

Fixes #1063.

@jsf-clabot
Copy link

jsf-clabot commented Aug 31, 2019

CLA assistant check
All committers have signed the CLA.

@@ -109,7 +109,7 @@ $.ajax({
<argument name="jqXHR" type="jqXHR"/>
<argument name="textStatus" type="String"/>
<argument name="errorThrown" type="String"/>
<desc>A function to be called if the request fails. The function receives three arguments: The jqXHR (in jQuery 1.4.x, XMLHttpRequest) object, a string describing the type of error that occurred and an optional exception object, if one occurred. Possible values for the second argument (besides <code>null</code>) are <code>"timeout"</code>, <code>"error"</code>, <code>"abort"</code>, and <code>"parsererror"</code>. When an HTTP error occurs, <code>errorThrown</code> receives the textual portion of the HTTP status, such as "Not Found" or "Internal Server Error." <strong>As of jQuery 1.5</strong>, the <code>error</code> setting can accept an array of functions. Each function will be called in turn. <strong>Note:</strong> <em>This handler is not called for cross-domain script and cross-domain JSONP requests.</em> This is an <a href="/Ajax_Events/">Ajax Event</a>.</desc>
<desc>A function to be called if the request fails. The function receives three arguments: The jqXHR (in jQuery 1.4.x, XMLHttpRequest) object, a string describing the type of error that occurred and an optional exception object, if one occurred. Possible values for the second argument (besides <code>null</code>) are <code>"timeout"</code>, <code>"error"</code>, <code>"abort"</code>, and <code>"parsererror"</code>. When an HTTP error occurs, <code>errorThrown</code> receives the textual portion of the HTTP status, such as "Not Found" or "Internal Server Error." (it will be an empty string in HTTP/2) <strong>As of jQuery 1.5</strong>, the <code>error</code> setting can accept an array of functions. Each function will be called in turn. <strong>Note:</strong> <em>This handler is not called for cross-domain script and cross-domain JSONP requests.</em> This is an <a href="/Ajax_Events/">Ajax Event</a>.</desc>
Copy link
Member

Choose a reason for hiding this comment

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

Do you have an authoritative source verifying that HTTP2 implementations on all browsers cannot return strings for this information? I don't have a problem saying that they "may be blank" for example, but this change implies that they must be blank and jQuery doesn't control this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you have an authoritative source verifying that HTTP2 implementations on all browsers cannot return strings for this information?

No. For example, Firefox does not return an empty string in violation of the specification. There is the open bug https://bugzilla.mozilla.org/show_bug.cgi?id=1397646. So I will replace it with "may be blank" as you suggested?

Copy link
Member

Choose a reason for hiding this comment

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

The thing we want to guard against is saying that it will be something when we simply pass through whatever the browser provides. how about adding "(which may be an empty string)" here? What was the case that led you to need this clarification?

Copy link
Contributor Author

@vkrol vkrol Sep 2, 2019

Choose a reason for hiding this comment

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

how about adding "(which may be an empty string)" here?

I agree with that.

What was the case that led you to need this clarification?

We encountered a couple of bugs on the production after we updated from HTTP/1 to HTTP/2 because we had comparisons with statusText and errorThrown in our code.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I changed the wording to it may be an empty string in HTTP/2.

Copy link
Member

@mgol mgol left a comment

Choose a reason for hiding this comment

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

A few grammar suggestions.

@dmethvin do they sound good to you?

@dmethvin
Copy link
Member

dmethvin commented Oct 5, 2019

Changes LGTM

@vkrol
Copy link
Contributor Author

vkrol commented Oct 5, 2019

@mgol thanks! Done.

@mgol
Copy link
Member

mgol commented Oct 5, 2019

@vkrol Thanks!

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

Successfully merging this pull request may close these issues.

HTTP/2 and errorThrown or statusText
4 participants