Re: [OAUTH-WG] OAuth and HTTP caching

[Eran Hammer-Lahav <eran at hueniverse.com>]

Can you give examples? Using curl it is as easy to include a header as it is to include a parameter. Can you give more details on the cases where all you had was a GET request without access to headers?

I am going to push back against the 'easier' arguments until I see use cases that truly require it and are core to what we are tasked to do.

EHL

> -----Original Message-----
> From: Justin Richer [mailto:jricher at mitre.org]
> Sent: Friday, September 25, 2009 10:42 AM
> To: Eran Hammer-Lahav
> Cc: Ethan Jewett; oauth at ietf.org
> Subject: Re: [OAUTH-WG] OAuth and HTTP caching
> 
> It is significantly easier to script a client library like these using
> HTTP parameters, and I have had a couple cases where all I had was a
> "get" style request to work with on my client. Using URLparams I was
> able to script this quite well, but if I needed to get into the
> headers,
> I wouldn't be able to do it.
> 
> I vote for having the auth headers be the recommended mode but for the
> parameters to stay around.
> 
>  -- justin
> 
> On Thu, 2009-09-24 at 14:24 -0400, Eran Hammer-Lahav wrote:
> > No, we are simply sending a message to browser vendors that they
> should add native support. It is one thing when a small community comes
> out with a spec and a whole other thing when the IETF publishes a new
> internet standard.
> >
> > Also, the fact that we will have the 1.0 spec published as an
> information RFC will help because it will give an alternative to this
> new work in cases where it is not possible to implement.
> >
> > EHL
> >
> > > -----Original Message-----
> > > From: oauth-bounces at ietf.org [mailto:oauth-bounces at ietf.org] On
> Behalf
> > > Of Ethan Jewett
> > > Sent: Thursday, September 24, 2009 11:04 AM
> > > To: oauth at ietf.org
> > > Subject: Re: [OAUTH-WG] OAuth and HTTP caching
> > >
> > > Thinking back ... wasn't one of the primary reasons for having a
> way
> > > to pass the authentication parameters that didn't involve the
> headers
> > > because in-browser javascript doesn't have access to the headers?
> > >
> > > Now, I don't think there are a lot of applications currently using
> > > OAuth to authenticate an in-browser client application directly to
> a
> > > server, but with the advent of mechanisms for cross-domain requests
> in
> > > HTML5 and through hacks like iFrame proxies, this might become more
> > > common. If we require authorization headers are we precluding the
> use
> > > of OAuth on the browser platform?
> > >
> > > Ethan
> > >
> > > On Thu, Sep 24, 2009 at 1:55 PM, Eran Hammer-Lahav
> > > <eran at hueniverse.com> wrote:
> > > > This means that we really only have two options:
> > > >
> > > > 1. Use only the HTTP Authorization header to pass authentication
> > > parameters from the client to the server. This means dropping
> support
> > > for URI query parameters and form-encoded body parameters.
> > > > 2. Drop support for form-encoded parameters, recommend using HTTP
> > > headers or require additional headers when using URI query
> parameters.
> > > >
> > > > Of course, #2 defeats the purpose because the only reason to keep
> URI
> > > query parameters is to avoid the need to set headers...
> > > >
> > > > Are there any *documented* reasons why we should not just limit
> OAuth
> > > to transmit parameters over HTTP Authorization headers?
> > > >
> > > > EHL
> > > >
> > > >> -----Original Message-----
> > > >> From: Roy T. Fielding [mailto:fielding at gbiv.com]
> > > >> Sent: Tuesday, September 22, 2009 10:48 AM
> > > >> To: Eran Hammer-Lahav
> > > >> Cc: John Panzer; oauth at ietf.org; ietf-http-wg at w3.org Group
> > > >> Subject: Re: [OAUTH-WG] OAuth and HTTP caching
> > > >>
> > > >> On Sep 22, 2009, at 10:24 AM, Eran Hammer-Lahav wrote:
> > > >>
> > > >> >> -----Original Message-----
> > > >> >> From: Roy T. Fielding [mailto:fielding at gbiv.com]
> > > >> >> Sent: Tuesday, September 22, 2009 10:09 AM
> > > >> >
> > > >> >> Just follow the HTTP spec.
> > > >> >
> > > >> > That what I am trying to figure out...
> > > >> >
> > > >> > Does the HTTP spec mandates that new authentication protocols
> use
> > > >> > the WWW-Authenticate and Authorization headers?
> > > >>
> > > >> HTTP is not aware of any other kinds of authentication.  There
> is no
> > > >> reason
> > > >> to specify anything else.
> > > >>
> > > >> > Are the headers required for existing caches and servers to
> > > operate
> > > >> > properly?
> > > >>
> > > >> Yes (and for user agents as well).  Don't forget about Proxy-
> Auth*.
> > > >>
> > > >> > If they are not included in authenticated requests, are there
> > > other
> > > >> > requirements to make sure it doesn't break existing
> deployment?
> > > >>
> > > >> Cache-control: private
> > > >>
> > > >> is probably needed if the Auth headers are not being used but
> the
> > > >> response depends on something like cookies for authentication.
> > > >>
> > > >> ....Roy
> > > >
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > OAuth at ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > > >
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth at ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> > _______________________________________________
> > OAuth mailing list
> > OAuth at ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth