Standard - Should Request File be in an extension spec?

[Michael Jones]

Yaron Goland asks whether the Request File functionality should be in an extension spec, as this doesn't seem like core functionality.

[Michael Jones]

Later in his comments on Standard he asks whether there are browers that can not support POST, which would allow them to use the request parameter method, putting the request in the POST body.

[Nat Sakimura]

It is related to #353

Also, it is one of the core deliverable in the charter.

In addition, the question is conflating a Client and a User-Agent.

Q. What is the URL length limit for the target browsers (e.g., i-mode) A. 500 bytes after URL encoded.

Q. Can't they just use POST? A. No. There are two cases at least:

Case 1: Older browsers - they do not support Javascript. As such, if POST were to be used, the user is forced to click on a button, which we know is broken. Case 2: Newer browsers (e.g., i-mode 2.0) - though it supports Javascript, does not support setRequestHeader, and thus XMLHttpRequest POST request generates Content-Type=text/xml and makes the web application impossible to receive the POST content. (cf. http://www.tokumaru.org/d/20100118.html ) They are pretty tricky right now.

Q. Is there any benefit in using request file other than for those awkward browsers? A. Yes. For slower connection (like EDGE or congested mobile network), it is much faster to use request file method than sending the entire request through the browser. Also, the request is cacheable. (Current spec has problem with nonce for this -- needs to be fixed.)

I do agree that it would be cleaner to separate the specs to each of the specific bindings, i.e., the OAuth Core Bidning, Request Parameter Binding, Request File (Artifact) Binding. The decision of the WG was to keep it in one document.