GithubHelp home page GithubHelp logo

whatwg / xhr Goto Github PK

View Code? Open in Web Editor NEW
309.0 64.0 128.0 1.95 MB

XMLHttpRequest Standard

Home Page: https://xhr.spec.whatwg.org/

License: Other

Makefile 0.09% HTML 99.91%
whatwg xmlhttprequest-standard xmlhttprequest standard

xhr's Introduction

This repository hosts the XMLHttpRequest Standard.

Code of conduct

We are committed to providing a friendly, safe, and welcoming environment for all. Please read and respect the Code of Conduct.

Contribution opportunities

Folks notice minor and larger issues with the XMLHttpRequest Standard all the time and we'd love your help fixing those. Pull requests for typographical and grammar errors are also most welcome.

Issues labeled "good first issue" are a good place to get a taste for editing the XMLHttpRequest Standard. Note that we don't assign issues and there's no reason to ask for availability either, just provide a pull request.

If you are thinking of suggesting a new feature, read through the FAQ and Working Mode documents to get yourself familiarized with the process.

We'd be happy to help you with all of this on Chat.

Pull requests

In short, change xhr.bs and submit your patch, with a good commit message.

Please add your name to the Acknowledgments section in your first pull request, even for trivial fixes. The names are sorted lexicographically.

To ensure your patch meets all the necessary requirements, please also see the Contributor Guidelines. Editors of the XMLHttpRequest Standard are expected to follow the Maintainer Guidelines.

Tests

Tests are an essential part of the standardization process and will need to be created or adjusted as changes to the standard are made. Tests for the XMLHttpRequest Standard can be found in the xhr/ directory of web-platform-tests/wpt.

A dashboard showing the tests running against browser engines can be seen at wpt.fyi/results/xhr.

Building "locally"

For quick local iteration, run make; this will use a web service to build the standard, so that you don't have to install anything. See more in the Contributor Guidelines.

Formatting

Use a column width of 100 characters.

Do not use newlines inside "inline" elements, even if that means exceeding the column width requirement.

<p>The
<dfn method for=DOMTokenList lt=remove(tokens)|remove()><code>remove(<var>tokens</var>&hellip;)</code></dfn>
method, when invoked, must run these steps:

is okay and

<p>The <dfn method for=DOMTokenList
lt=remove(tokens)|remove()><code>remove(<var>tokens</var>&hellip;)</code></dfn> method, when
invoked, must run these steps:

is not.

Using newlines between "inline" element tag names and their content is also forbidden. (This actually alters the content, by adding spaces.) That is

<a>token</a>

is fine and

<a>token
</a>

is not.

An <li> element always has a <p> element inside it, unless it's a child of <ul class=brief>.

If a "block" element contains a single "block" element, do not put it on a newline.

Do not indent for anything except a new "block" element. For instance

 <li><p>For each <var>token</var> in <var>tokens</var>, in given order, that is not in
 <a>tokens</a>, append <var>token</var> to <a>tokens</a>.

is not indented, but

<ol>
 <li>
  <p>For each <var>token</var> in <var>tokens</var>, run these substeps:

  <ol>
   <li><p>If <var>token</var> is the empty string, <a>throw</a> a {{SyntaxError}} exception.

is.

End tags may be included (if done consistently) and attributes may be quoted (using double quotes), though the prevalent theme is to omit end tags and not quote attributes (unless they contain a space).

Place one newline between paragraphs (including list elements). Place three newlines before <h2>, and two newlines before other headings. This does not apply when a nested heading follows the parent heading.

<ul>
 <li><p>Do not place a newline above.

 <li><p>Place a newline above.
</ul>

<p>Place a newline above.


<h3>Place two newlines above.</h3>

<h4>Placing one newline is OK here.</h4>


<h4>Place two newlines above.</h4>

Use camel-case for variable names and "spaced" names for definitions, algorithms, etc.

<p>A <a for=/>request</a> has an associated
<dfn export for=request id=concept-request-redirect-mode>redirect mode</dfn>,...
<p>Let <var>redirectMode</var> be <var>request</var>'s <a for=request>redirect mode</a>.

xhr's People

Contributors

annevk avatar autokagami avatar clelland avatar cybai avatar domenic avatar fictionistique avatar foolip avatar gterzian avatar jakearchibald avatar jenseng avatar jugglinmike avatar kichjang avatar lucacasonato avatar ms2ger avatar noamr avatar rashika101 avatar ricea avatar ryoqun avatar sideshowbarker avatar takenspc avatar tkent-google avatar ykzts avatar yutakahirano avatar zcorpan avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

xhr's Issues

Should XHR store and send HTTP header names in lower case?

The XHR spec defers HTTP header handling to the Fetch spec, and the header names are byte-lowercased in Fetch spec.
https://xhr.spec.whatwg.org/#the-setrequestheader()-method
https://fetch.spec.whatwg.org/#terminology-headers

However, all major browers don't normalize them at this point. I think this is due to compatibility issue around legacy servers that may handle the header names in case-sensitive manner.
OTOH, I found it's beneficial for Chrome in terms of cleaner code and better performance to normalize all request / response header names to lowercase.

So, I want to confirm that the XHR is expected to use lowercase header names. Or is that actually expected to pass through the overridden request headers as-is?

Help

untitled
What does this mean?

what is the problem

Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience.

null for response in case of invalid JSON

JSON body parsing algorithm states that trying to parse a response which is an invalid JSON (thus, making JSON.parse throw an exception) will result in setting null to the response property. But according to ECMA-404 (but not to RFC 4627), null is a valid JSON. So there is no way to distinct a valid response containing null and an invalid JSON.

Document responses and responseXML should be null in workers

Workers shouldn't have access to Document objects, and WPT even tests for this in workers/semantics/xhr/001.html, however the spec doesn't seem to say anything about response (where responseType=="document") and responseXML when being evaluated from a worker context.

Perhaps we should be early-returning null in both cases?

Fix Fetch integration

Currently building XMLHttpRequest fails because Fetch changed a few things around due to Streams integration.

@yutakahirano you were going to fix that, right?

Ajax call to server in synchronous mode <> disrupt user experience!

https://xhr.spec.whatwg.org/#sync-warning

I just had Google Chrome block my ajaxObj.open('POST','StdGradReSet.aspx',false); because it was synchronous and would "disrupt the user experience". I have built an online web application program that depends on this action being synchronous as it is a modal state required to prevent data corruption in the program. If the server is being a bit slow, that is expected in this case and is not a problem. What is a disruption of the "user experience" is blocking the call and preventing the operation from taking place even if it is "slow" by a second or two. I understand this problem in some web site cases uses, but that does not apply in a full application program where modal action is required. If the server is slow in responding that is a server management issue, not a browser enforcement problem. At this point in time, the ajax object .open command does not have a timeout option in it that can be set and handled within the command itself, or any way to set the modal action on intent. Please provide an alternative option in the command to explicitly determine modal action and not block it. Band-aiding this by forcing asynchronous processing and use of the .onreadystatechange event only causes data corruption problems for data processing applications.

Bob Curtice
Web Software Developer

FormData's append method does not match browsers

https://xhr.spec.whatwg.org/#interface-formdata

The append(name, value, filename) method, when invoked, must run these steps:โ€‹

See discussion in jsdom/jsdom#1533

Given this code:

var formData = new FormData();
var file = new Blob([
   JSON.stringify({})
], { type: 'application/json' });
formData.append('somename', file);
formData.entries().next().value

My reading is that per the spec this should append a new entry whose name is "somename" and whose value is a Blob to the form data. Then, entries().next().value should return the Blob right back.

However, apparently in Chrome and Firefox it does not do that. Instead it converts it to a File (not a Blob) with, at least in Chrome, name "blob".

Abandon hope of removing sync XHR from the web platform?

https://xhr.spec.whatwg.org/#sync-warning

Synchronous XMLHttpRequest outside of workers is in the process of being removed from the web platform as it has detrimental effects to the end user's experience. (This is a long process that takes many years.) Developers must not pass false for the async argument when the JavaScript global environment is a document environment. User agents are strongly encouraged to warn about such usage in developer tools and may experiment with throwing an InvalidAccessError exception when it occurs.

There are some Blink use counters for sync XHR:
https://www.chromestatus.com/metrics/feature/timeline/popularity/465 (measure only)
https://www.chromestatus.com/metrics/feature/timeline/popularity/472 (deprecated)
https://www.chromestatus.com/metrics/feature/timeline/popularity/581 (deprecated)
https://www.chromestatus.com/metrics/feature/timeline/popularity/677 (async for comparison)

This does not look at all promising. There's a slight downwards trend, but starting from >2% it's hard to see it dropping to the point where removal is possible.

Synchronous XMLHttpRequest outside of workers deprecation is not a good idea.

In most cases, I agree that synchronous requests should be avoided. I fully understand why they should be avoided. I strongly disagree with the decision to deprecate them. We are talking about programmers and tools here, not children and knives.

In some cases, synchronous requests are a life saver: Let's say I have a 3rd party component, like jQueryUI datepicker, and there is a user-override-able callback for a feature of the control (like getting the current time). In this case, we'll get the time from the server with an ajax request (since we can't assume the clock on the client side is correct).

If that request has to be asynchronous, how do I keep the rest of the 3rd party code from merrily chugging away before I get the date back from the server? Continuations aren't much help here (unless I want to wrap the remainder of each callback-calling function in the 3rd party library as a function passed to a continuation).

Don't use "JavaScript global environment"

The usages here are much simpler than those in HTML, it seems. You can e.g. replace

If the JavaScript global environment is a document environment

with

If the entry settings object's global object is a Window

and

If the JavaScript global environment is a worker environment

with

If the entry settings object's global object is not a Window

Hmm, I guess HTML can do that too, brb... It's much easier once you realize that it's not possible to access a worker-version of the constructor from a window, and vice-versa.

"For the purposes of interaction with other algo..."

https://xhr.spec.whatwg.org/#interface-formdata

For the purposes of interaction with other algorithms, an entry's type is "string" if its value is a string and "file" otherwise. If an entry's type is "file", its filename is "blob" if value is not a File object, and otherwise its filename is the value of entry's value's name attribute.

I don't see any good reason to force 'blob' as filename here: a File can have an empty name, and a HTMLInputElement type=file, if not set, contains a blob without name. This makes an inconsistent behavior between a form submission and FormData.

Creating an ArrayBuffer can fail

When a new ArrayBuffer object is created this can throw a RangeError. We need to decide how to deal with that.

Gecko throws the exception from the response getter as long as allocation keeps failing. But it might be simpler to return null. That means developers won't have to expect exceptions from using a simple getter and don't have to write complicated code to keep trying to get an ArrayBuffer allocated in a loop.

XHR using sync warning

https://xhr.spec.whatwg.org/#sync-warning

Synchronous XMLHttpRequest outside of workers is in the process of being removed from the web platform as it has detrimental effects to the end user's experience.

Despite there being many, many cases in which synchronous results are preferred and would not be detrimental to the user's experience, clearly, this nonsense is happening anyway. So... why not put a link to a page offering alternative solutions to how to use Async XHR in a manner that satisfies the common needs of what Sync XHR would be used for. Rather than just saying "don't do that", you should say "do this instead". Don't take things away without offering replacements.

Rephrase "Synchronous XMLHttpRequest" warning

https://xhr.spec.whatwg.org/#sync-warning

Synchronous XMLHttpRequest outside of workers is in the process of being removed from the web platform as it has detrimental effects to the end user's experience. (This is a long process that takes many years.) Developers must not pass false for the async argument when entry settings object's global object is a Window object. User agents are strongly encouraged to warn about such usage in developer tools and may experiment with throwing an InvalidAccessError exception when it occurs.

This statement/deprecation is related to the way browsers do handle the (a)sync behavior.
Whether it has (or not) any "detrimental effects to the end user's experience" is subjective and should not be a valid argument.

Synchronous means it should not proceed to the next javascript statement until the request is complete, none said that browsers should freeze the UI by launching the request in the main thread...

Think about the "alert()" or "confirm()" in javascript. Those are synchronous because they block the execution of the script but it does not have "freeze" effects and does not have such "detrimental effects to the end user's experience" (subjective again).

So the specification should not be backing off the synchronous capability because browsers do implement it the wrong way.

Wrong state after abort()

The abort() method, as in the spec:

  1. Terminate the request.
  2. If state is either opened with the send() flag set, headers received, or loading, run the request error steps for event abort.
  3. If state is done, set state to unsent.

Consider this:

var xhr = new XMLHttpRequest(); // UNSENT
xhr.open('GET', '');            // OPENED with send() flag unset
xhr.abort();                    // UNSENT

Following the spec, nothing should happen in steps 2 and 3, leaving the state OPENED. This breaks web-platform-tests/abort-during-open, which expects UNSENT.

From what I've seen, abort() was last changed in the scope of #54.

At this point I have no good suggestion on how to reformulate it to pass web-platform-tests/abort-during-open and web-platform-tests/open-during-abort, as both get to step 3 with "OPENED with send() flag unset", but the final status is expected to be different.

Should we be pinning Blob URIs on fetches?

Ref https://github.com/w3c/web-platform-tests/blob/master/FileAPI/blob/Blob-XHR-revoke.html

    var blob = new Blob(["test"]);
    var url = URL.createObjectURL(blob);
    var xhr = new XMLHttpRequest();
    xhr.open("GET", url);

    URL.revokeObjectURL(url);
    xhr.onload = function() {console.log(xhr.response)}
    xhr.send();

Firefox has interesting behavior when it comes to revoked blob URIs.

If, for example, you call xhr.open() on a nonrevoked blob URI, that URI can be fetched via XHR even after it is revoked. Newer fetches (via XHR or otherwise) cannot access it, however, only fetches opened before the revocation.

Additionally, calling xhr.open() on a revoked URI will error. I'm not so fond of this behavior myself, I don't think open() should be erroring on valid but nonexistant URIs since that can be unexpected behavior -- it should instead wait for the send() and error then.

We should discuss getting some or all of this behavior into the spec, or removing it if not desired.

cc @izgzhen @Baku @annevk

abort() handling of state is busted

Consider this testcase:

var xhr = new XMLHttpRequest();
xhr.open("GET", "data:text/plain,");
console.log(xhr.readyState);
xhr.send();
xhr.onreadystatechange = function() {
  xhr.onreadystatechange = null;
  xhr.open("GET", "data:text/plain,hello");
  xhr.onload = function() { alert(xhr.responseText); }
  xhr.send();
}
xhr.abort();
console.log(xhr.readyState);

per the letter of the current spec, this should log 1 then 0. And it should alert "hello". This is the behavior I see in Blink and WebKit. However, this means that after the abort() call the readyState is 0 but there is a load in progress. That's the busted part.

Gecko has a guard in abort() step 3 and only reset the state to "unsent" if it's still "done" after the request error steps and all their events have terminated. This leaves state as a correct reflection of the actual state of the object.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.