Re: [Regops] draft-wullink-restful-epp-00.txt
"Linlin Zhou" <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <000301cd21f3$c2759df0$4760d9d0$@cn> |
You mean cookie based session? Is the cookie stored on the client side or included in the http header or url for every request? In the first case, if the cookie is disabled by the client, does it still work? If the second case, things like header or url length limit, replay attack may cause problems. Or we can generate and manage the authentication information by ourselves, so creating sessions is not necessary. Linlin Zhou CNNIC > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Francisco Obispo > Sent: Tuesday, April 24, 2012 1:06 AM > To: Gould, James > Cc: [email protected]; [email protected]; Rubens Kuhl > Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt > > > You could initiate a session with a RESTful server, just like most websites work: > > - You will use a RESTful URL to create a session: /session/user_id [POST] > > - The server would return a cookie, which you will return with every RESTful > request. > > - When you're done processing requests you can: /session/user_id [DELETE] > > The advantage of this model, is that you can use the existing knowledge on how > to scale web-services and apply them to Registry-Registrar interactions. > > Francisco > > > > > On Apr 23, 2012, at 9:26 AM, Gould, James wrote: > > > Passing the user credentials to authenticate the user on a per command > > basis will also add a lot of extra overhead. Can someone describe how > > these elements will be mitigated in a stateless model? Overall, I > > don¹t see how moving from stateful to stateless will benefit either > > the client or the server from a performance or load perspective. > > Francisco Obispo > email: [email protected] > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE > > _______________________________________________ > provreg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/provreg _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg