HTTP library requirements

Servo has some unique requirements when it comes to interacting with the networking stack.

• Raw byte access to HTTP header content
  • for XHR’s setRequestHeader and getResponseHeader methods
  • Most of the Fetch spec deals with raw headers.
• Raw access to the original socket for WebSockets
  • the initial connection is an HTTP request to the server with the Upgrade field present, and subsequent non-HTTP communication on the same socket proceeds after the server's response is received
• Must be as liberal as possible in accepting data, because the physical world is so made that it provides the capability to computers to send arbitrary bytes sequences to one another.
• Complete control over handling all HTTP response codes (e.g. ability to follow or not follow redirects).
• Ability to easily tie end-to-end state to an HTTP request/response + redirects (e.g. for implementing content security policy).
• Ability to cancel HTTP transactions.
• Request prioritization, including for requests that have already been made (e.g. by throttling on the TCP level and so forth; talk to Patrick McManus about the work he's done on Necko to support this sort of thing).
• Request introspection
  • needed to support APIs like ServiceWorker, which intercept requests before they are initiated
• Synthesizing responses
  • needed for ServiceWorker, which allows content JS to replace an intercepted request with an arbitrary synthesized response
• Upload/download progress notifications.
  • Ability to query for exact progress of an upload, not just chunk-wise.
• Proxy support? Unclear where this should happen.
• Sufficient API surface for timing information to implement performance/resource timing APIs.
• Ability to deliver response data on a thread other than the one that started the request.
• Possibly hooks on responses/requests to allow extensions to mess with them.