[fetch] RFC: a mechanism to bypass CORS preflight (#210)

CORS preflight introduces a significant delay even with browser-side caching, for examples for use cases when an application initiates its first interaction with a service whose response will bootstrap the client application. 

To address this latency problem, we'd like to propose the following general solution:

1. Have the client encode the HTTP method via a special URL parameter agreed with the server that provides the resource or service. Use POST if the request has a body; or GET otherwise.

2. Have the client encode any non-whitelisted HTTP headers via a special URL parameter agreed with the server. The parameter value needs be URL encoded with the format being an HTTP/1.1 header block as  1*(<header-name> : <header-value> \r \n)

Since a server that does not understand the above URL parameters will not take any action, this approach in itself should not introduce any CORS related security vulnerability.

On the server side, the real HTTP method or any custom HTTP headers that the client is generating are expected to be set to the request object immediately before the request is dispatched to the application logic (commonly known as handlers, servlets etc). That is, the server run-time does not need be aware of this optimization.

Comments welcome, esp. on the security side. Thanks to Takeshi Yoshino for the initial review.

- Wenbo Zhu (Google, cloud networking)

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/210