Dick Hardt wrote: >>> >>> Supporting payloads larger then 2K is a requirement. >> >> I guess I don't understand what this 2K limit is (and this is not >> mentioned in the spec) - are you talking about limits on the URL size >> when doing an HTTP GET? > > yes > >> If so, why not use POST instead? > > Now I am really confused about what you are talking about
I /think/ the limit you are talking about is that regarding the size of the URL. The reason you might approach or exceed that limit would be if you were sending an HTTP GET with parameters appended to the URL. The solution to that issue is to encode the data as an HTTP FORM POST, which, AFAIK has no such limit. As I understand it, that would be a separate issue than whether the protocol is transacted via HTTP 3XX redirects through the user-agent, vs. making the user-agent do the redirect "manually". But as I mentioned, I have to admit I'm not totally sure what 2K limit you're actually talking about. >>> >>> How would you suggest the servers determine wether to use GET or POST? >> >> Can't YADIS be used to obtain such metadata from the IdP? > > That does not make any sense. You are stating that the user agent might > not be able to support JS. Not supporting JS would mean the RP / OP > would need to figure out what the user agent supported so that it could > decide on using GET or POST. I'm expecting that the servers can use existing means (determining the browser type and version through the user-agent string) if they want to try that. But what I meant was that the servers (RP and IdP) have to agree on whether they will use one thing or the other, no? The RP could just try it out I guess, but it could also look in the IdP's YADIS doc. and find out whether the authentication service at the IdP supports GET, POST or both. - John _______________________________________________ specs mailing list [email protected] http://openid.net/mailman/listinfo/specs
