[Twisted-web] HTTP-AUTH for web2 / Kudos on web2's operation

[Clark C. Evans]

On Fri, Nov 18, 2005 at 05:54:19PM -0600, L. Daniel Burr wrote:
| Just a comment from the peanut-gallery: As a person who is currently 
| using  web2, I want to weigh in heavily on the side of "restrict the 
| applications  of twisted.web2 to object publishing".  The way in which 
| web2 publishes  objects fits very nicely with the way Roy Fielding 
| describes REST, at  least insofar as my understanding of REST goes.

In Roy Felding's REST model, a Resource is a function mapping t (time)
into a representation for that resource, where a representation is a set
of entities (byte streams) which are logically equivalent. According to
Felding, a Resource must have a semantic definition "that distinguishes
one [resource] from another". In the practical implementation of his
model, URIs become resource identifiers, a unique name for a given
resource, and the content returned are the entities which, for all
of those requesting the resource, must be logically equivalent at a
particular period in time t.  

The fun part of Felding's model is that a Resource (at a point in time)
is a _set_ of equivalent entities, where by the actual entity returned
for a give request is determined by "Content Negotiation".  Hence,
different media types (say an XML or JSON or PNG) of a given set of
information may be returned depending upon the negotiation between the
client and the server.  However, the semantic meaning of the actual
entity returned must be equal for _all_ possible content negotiations.
A Resource refers to a 'concept', rather than a particular representation
of that concept at a particular point in time; but it also implies a 
certain amount of consistency between its representations.

The particular notion of REST is that all interactions are stateless:
"each request contains all of the information necessary for a connector
to understand the request independent of any requests that may have
preceded it".  In other words, no server side state or cookies should
be used.  While this is great for routine operations; it falls short
when doing 'authentication', which, according to the specifications
themselves requires server-side state (the challenge must be
remembered).  Felding criticizes Cookies in his paper but does not seem
to propose an alternative solution to address user authentication
concerns.  For most purposes, this stateless property is a fantastic
goal to strive for; however, it is not and should not be a rule.

While "object publishing" may support REST semantics, it is not
the only possible way to be REST; and there is no reason why Twisted
should require this model if it isn't absolutely necessary.

| Every Resource *should* be identified by a URL, and that URL *should*  
| refer to one logical Resource.  This is how the web works today; I for  
| one, hope that it continues to do so.

It should be noted that Felding and most others do not require that the
relation from URIs onto Resources be injective -- that is, two different
URIs may (and often do) refer to the same Resource. The object
publishing methodology seems to imply (or assume?) an injective relation
between URIs and Resources.  This is not a necessary assumption.

I certainly do not suggest that the same URI should refer to two
different resources; however, it is certainly valid for two _different_
URIs to refer to the same resource, and Twisted's web2 should support
this methodology -- or at least be neutral towards it.

| That said, I'm completely in favor of coming up with sane mechanisms for  
| Sessions and Auth.  Changing web2 such that the a singly-rooted tree of  
| Resources is no longer the base metaphor should not be a requirement for  
| implementing Sessions and Auth.

Part of the problem with Sessions (or Authentication in general) is that
it requires server-side state.  With the _sole_ exception of the user's
identity, my application is completely stateless.  However, I've yet to
see a "stateless authentication" mechanism.  If you have one, great!

| It seems to me that you'd be much happier with a WSGI solution, wherein  
| you can just plug your request-processing, session-handling, foo-handling 
| components into the stream at appropriate places.  Web2 supports WSGI  
| already, so that might be a better route to take.

I didn't notice; but it looks like a good option.  Thanks for pointing
it out to me.

| Then you can implement 
| the model that best suits your application, while leaving web2's object  
| publishing model intact for those of us that vastly prefer it.

I have no problem with web2's object publishing mechanism; my problem is
that such a system could easily be layered on-top of a simpler
interface -- but it isn't.

Kind Regards,

Clark