XMLHttpRequest Tests


This is a set of functional tests for client-side HTTP libraries (e.g., XMLHttpRequest and Microsoft.XMLHTTP).

This is not a compliance or conformance test suite; an implementation can fail many of the tests here and still be HTTP conformant. Instead, the idea is to show what HTTP mechanisms different implementations support, and how they support them, since many aspects of these libraries are underdefined.

Each group of tests explains what is being tested and what the implications of failure are. Although many of the tests are automated, some may require user interaction, via a "run test" button. Be sure to follow any instructions carefully.

For discussion or to leave feedback, see the announcement.


Are relative URIs resolved correctly?

Relative references can contain "dot segments" that need to be removed before using the URI to send a request. Implementations that fail these tests may send incorrect requests.

  1. resource:
  2. ./resource:
  3. ../resource:


HTTP isn't just GET and POST; other methods ar defined by RFC2616 and other specifications, and should be available to Web authors. Additionally, methods are case-sensitive, and therefore the case should be preserved.

What Methods Are Available?

  1. GET:
  2. Get:
  3. HEAD:
  4. POST:
  5. PUT:
  6. DELETE:
  7. TRACE:
  8. FOO:
  9. Foo:


Are redirects handled by the implementation, or passed through?

HTTP allows user-agents to automatically handle some redirect response status codes, so that the user doesn't have to make a separate request. Implementations that fail these tests don't do this, and will require calling code to handle redirects themselves.

  1. 301 Moved Permanently:
  2. 302 Found:
  3. 303 See Other:
  4. 307 Temporary Redirect:

Are methods preserved correctly?

If an implementation automatically handles a redirect, it must use the appropriate request method. HTTP requires receivers of some redirects to change the request method to GET; others are required to use the original method. Implementations that fail these tests will send redirected requests with the wrong HTTP methods.

Note that the upcoming revision of HTTP allows rewriting the method from POST to GET for status codes 301 and 302.

  1. 301 Moved Permanently, POST:
  2. 301 Moved Permanently, GET:
  3. 301 Moved Permanently, HEAD:
  4. 301 Moved Permanently, PUT:
  5. 301 Moved Permanently, DELETE:
  6. 302 Found, POST:
  7. 302 Found, GET:
  8. 302 Found, HEAD:
  9. 302 Found, PUT:
  10. 302 Found, DELETE:
  11. 303 See Other, POST:
  12. 303 See Other, GET:
  13. 303 See Other, HEAD:
  14. 303 See Other, PUT:
  15. 303 See Other, DELETE:
  16. 307 Temporary Redirect, POST:
  17. 307 Temporary Redirect, GET:
  18. 307 Temporary Redirect, HEAD:
  19. 307 Temporary Redirect, PUT:
  20. 307 Temporary Redirect, DELETE:

Are redirects automated appropriately?

Implementations that handle redirects automatically are required by HTTP to force user intervention before some combinations of request method and redirect status code are handled automatically. Those that fail these test do not do so, and therefore may cause dangerous requests to be made.

For example, if Alice's browser that doesn't check with her before redirecting a POST to another server, this could be exploited to change her data on a third-party server (e.g., her bank) without her knowledge.

  1. GET to a 301 Permanent Redirect:
  2. POST to a 301 Permanent Redirect:
  3. PUT to a 301 Permanent Redirect:
  4. DELETE to a 301 Permanent Redirect:
  5. GET to a 302 Found:
  6. POST to a 302 Found:
  7. PUT to a 302 Found:
  8. DELETE to a 302 Found:
  9. GET to a 303 See Other:
  10. POST to a 303 See Other:
  11. PUT to a 303 See Other:
  12. DELETE to a 303 See Other:
  13. GET to a 307 Temporary Redirect:
  14. POST to a 307 Temporary Redirect:
  15. PUT to a 307 Temporary Redirect:
  16. DELETE to a 307 Temporary Redirect:


Is authentication automatically populated?

When the user-agent has already established HTTP authentication credentials for a resource, will it automatically use them for requests? Implementations that fail these tests won't automatically supply authentication information for requests, even if the user is already authenticated.

Follow this link before running the test, supplying a username of "test" and a password of "test" when challenged.

  1. Sync:
  2. Async:

Does unhandled authentication pop up a dialog?

When the user-agent has not established HTTP authentication credentials for a resource, will it prompt the user for them? Implementations that fail these tests will require that the user is authenticated before making any requests.

When running this test, cancel out of any authentication dialog that is presented.

  1. Sync:
  2. Async:


Is the Referer request header set?

Some Web applications use the referer header for access control, site statistics, etc. While HTTP does not require that it be sent, implementations that fail this test will rule out using the referer header for such purposes.

  1. Referer:


Are Set-Cookie headers in responses stored and resent later?

Implementations that fail this test won't interoperate with servers that use cookies to maintain state.

Restart your browser or remove cookies in this domain before reloading this test.

  1. Set-Cookie:


Is the Accept-Encoding request header set?

Content-coding allows representations to be compressed, saving bandwidth and reducing end-user perceived latency. Implementations that fail these tests do not advertise themselves as being capable of handling content-codings to the server.

  1. gzip:
  2. deflate:
  3. compress:

Are content-coded responses decoded by the implementation?

Implementations that fail these tests do not automatically decode content-coded responses, requiring special handling (often, ruling out the use of content-coding altogether).

  1. gzip:
  2. x-gzip:
  3. compress:
  4. x-compress:

Creative Commons License