No subject


Wed Mar 4 18:19:19 UTC 2009


&gt; Disallowing post responses limits the use of the more verbose<br>
&gt; extensions (e.g. attribute exchange). =A0While this might be acceptabl=
e<br>
&gt; for Luke&#39;s particular use case, it might leave it unsolved for oth=
ers.<br>
<br></div>
The POST response is a good point and clearly a valid use case, and I think=
 it=92s supported no matter what we decide to do. It=92s possible to build =
a receiver that handles POST params if they are present, but otherwise serv=
es up the correct cache headers and Javascript to handle the GET. That woul=
d provide a performance boost in the common case, while still being fully c=
ompatible with the spec.<br>

</span></font></div></blockquote><div><br>For what it&#39;s worth, we went =
through a similar discussion when we were trying to define a version of OAu=
th for &quot;unregistered&quot; consumers, and are proposing the following =
there (<a href=3D"http://step2.googlecode.com/svn/spec/unregistered_oauth/l=
atest/oauth-unregistered.html">http://step2.googlecode.com/svn/spec/unregis=
tered_oauth/latest/oauth-unregistered.html</a>):<br>
<br>- use POST by default, to reduce the risk posed by open redirectors (wh=
ich tend to not redirect on a POST)<br>- when using GET (which can be reque=
sted by the consumer), put the sensitive payload into the fragment. This ha=
s the performance benefit Luke mentions if the consumer is Javascript, _plu=
s_ also helps with open redirectors - the sensitive payload doesn&#39;t hit=
 the servers and most browsers drop it across 302s.<br>
<br>Dirk. <br><br><br></div><blockquote class=3D"gmail_quote" style=3D"bord=
er-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-l=
eft: 1ex;"><div><font face=3D"Calibri, Verdana, Helvetica, Arial"><span sty=
le=3D"font-size: 11pt;"><br>



More information about the specs mailing list