[
Lists Home |
Date Index |
Thread Index
]
On Thu, 31 Mar 2005 01:00:29 -0500 (EST), Rich Salz <rsalz@datapower.com> wrote:
> I didn't think I was arguing SOAP v REST. Tweaking some claims,
> perhaps. :)
>
> > Yes, Digest does include the URI in the hash.
>
> The more correct synopsis would add "but Digest isn't practical"
For your context in which you are working that may be true, and I accept that.
> > Yes, SLL is tied to the IP address of the server being accessed.
>
> Here the text to add is "or an entity in 'front of' the server
> terminating the SSL connection."
>
You have mentioned this before, but is there anything
which stops you from using TLS/SSL on all the hops
*after* the firewall?
> > And POE does exactly that, if you miss the reply to your POST
> > then do your POST again, if you get a 405 then you know that the
> > first POST went through and you can do a GET on the
> > same URI to get the response body.
>
> I don't think POE works without first doing a GET so that you
> can get the POE-Links URL to tell you where to go if you're
> POST doesn't get a response.
That first GET is for the hypertext that contains the POE link, correct.
That's part of the 'hypermedia as the engine of application state", but
let's not go there :)
> Nor does POE have a strong way
> to prevent anyone else from getting the response, either.
I understand that you have issues with the current authentication
and encryption mechanisms for HTTP.
What I don't understand is the underlying assumption that
Basic and Digest are the end of the line for HTTP authentication.
RFC 2617 not only defines Basic and Digest but puts in
place a framework for adding new mechanisms.
In fact, two such extensions have been proffered during the course
of the Atom discussions[1][2], with the WSSE based mechanism being
adopted by TypePad and, until recently, Blogger. Blogger has since
switched to using Basic over SSL.
-joe
[1] http://bitworking.org/news/New_AtomAPI_Implementation_Release2
[2] http://www.xml.com/pub/a/2003/12/17/dive.html
--
Joe Gregorio http://bitworking.org
|
