-
Notifications
You must be signed in to change notification settings - Fork 264
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
Conversation
entries/jQuery.ajax.xml
Outdated
@@ -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> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
.
There was a problem hiding this 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?
Changes LGTM |
@mgol thanks! Done. |
@vkrol Thanks! |
Fixes #1063.