[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AD Evaluation of draft-ietf-atompub-protocol-11
Lisa Dusseault wrote:
Cookie support, sessions, authentication
Is there an assumption that clients MUST support cookies?
No, there is no such assumption.
There may be an assumption that the server will not require this of
clients. In fact, I would argue that a server which does require cookies
is seriously broken. Perhaps that should be spelled out.
without such
a requirement explicitly stated, some clients won't, for reasonable
security concerns. Instead, is there an assumption that clients MUST
repeat authentication headers with each request? Or will servers
effectively end up constantly "reminding" clients (through 401 errors)
to authenticate?
The former. This is standard HTTP practice.
This might seem obvious but it definitely differs from
regular HTTP practice where clients authenticate once and then stop
sending authentication information automatically and it just works
because of cookies.
That's not standard HTTP practice at all. That's an ugly hack that
completely bypasses HTTP authentication.
Also we'd experienced this as an interoperability
problem in WebDAV interoperability tests where some server implementors
insisted that certain WebDAV clients were completely broken in not
supporting cookies.
That's because WebDAV violates the HTTP architecture six ways to Sunday,
and tries to pretend the Web is just a funny kind of LAN. By contrast
APP is being designed in accordance with the design of HTTP rather in
active conflict with it. Assuming we can educate developers about what
this means, there shouldn't be the sort of Broken-by-design problems
WebDAV encounters.
Hmm, that's actually a pretty big assumption. I suspect there will be
problems; but at least they should be able to be cured short of changing
the spec. I don't think we should turn the APP spec into an HTTP
tutorial, even if such a document is sorely needed. (It might not hurt
to publish one separately though, maybe as an informational RFC?)
Are there assumptions that sessions will be maintained through
persistent connections? I believe there should be none. That is, if
you're a client implementor thinking that the first request will contain
authorization and subsequent requests on the same connection have no
authorization, think again.
APP is based on HTTP and REST. In accordance with this architecture,
there are no sessions to maintain. Worrying about session maintenance in
APP makes about as much sense as worrying about trimming the jibs on the
Autobahn.
--
Elliotte Rusty Harold elharo@xxxxxxxxxxxxxxx
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/