Re: [decade] Remote Get Object Message

[Dirk Kutscher <[e-mail]>]

Hi,

So, I agree that DECADE should not introduce new HTTP headers, let alone new message types, without real good reasons.

Regarding GET vs. POST, I think it will be important to have a closer look at the protocol semantics. For example, if it is just HTTP-GET semantics and DECADE is using URI types that existing proxies understand (http in this case), HTTP-GET should be used (to enable using existing proxies).

But there can be reasons to use POST, specifically if the DECADE protocol used non-HTTP URI types*and* existing proxy infrastructure should be used. In that case, it may be better to use POST (with a well-known local part of the URI, e.g., as in http://example.com/decade/get) and to provide DECADE request parameters such as the object name in form data parameters. It can be possible to cache responses to those requests (requiring cache-control headers).

Best regards,
Dirk


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Richard Alimi
> Sent: Samstag, 12. Mai 2012 20:19
> To: Songhaibin
> Cc: [e-mail]
> Subject: Re: [decade] Remote Get Object Message
> 
> I'm late to the game, but I agree that using the proxy concept for remote-get
> and standard (simple) operations for the others seems pretty clean.
> 
> Rich
> 
> On Tue, Apr 17, 2012 at 7:23 PM, Songhaibin <[e-mail]>
> wrote:
> > I also agree with that using standard HTTP GET and POST can be better
> > for remote get behavior and server to server data communication than
> > inventing new headers. I also agree with the non-transparent proxy
> concept.
> >
> >
> >
> > BR,
> >
> > -Haibin (as contributor)
> >
> >
> >
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Rahman, Akbar
> > Sent: Tuesday, April 03, 2012 9:55 PM
> >
> >
> > To: Woundy, Richard
> > Cc: [e-mail]
> > Subject: Re: [decade] Remote Get Object Message
> >
> >
> >
> > Hi Rich,
> >
> >
> >
> >
> >
> > Yes, that is a good point.  I agree that for server-server
> > communications (without a client involved) then standard HTTP GETs,
> > PUTs and POSTs could be used without need for new headers or methods.
> >
> >
> >
> >
> >
> > Akbar
> >
> >
> >
> >
> >
> >
> >
> > From: Woundy, Richard [mailto:[e-mail]]
> > Sent: Monday, April 02, 2012 3:53 PM
> > To: Rahman, Akbar
> > Cc: [e-mail]; Woundy, Richard
> > Subject: RE: [decade] Remote Get Object Message
> >
> >
> >
> >> However, I guess this model breaks down if we are required to support
> >> a use case where "DECADE server-1" wants to exchange content with
> >> "DECADE server-2" without being triggered by a client.
> >
> >
> >
> > Yes I would tend to agree. One *could* make this look like a proxy
> > case by forcing server-1 to act as its own proxy, but that seems inelegant.
> >
> >
> >
> > But then I would imagine that server-1 could obtain content from
> > server-2 using a simple HTTP GET, and could push content to server-2
> > using a simple HTTP POST, right? We still wouldn't need a new
> > X-DECADE-ORIGIN header or a new HTTP message, right?
> >
> >
> >
> > -- Rich
> >
> >
> >
> > From: Rahman, Akbar [mailto:[e-mail]]
> > Sent: Friday, March 30, 2012 8:40 PM
> > To: Woundy, Richard
> > Cc: [e-mail]
> > Subject: RE: [decade] Remote Get Object Message
> >
> >
> >
> > Hi Rich,
> >
> >
> >
> > I agree that using a classic HTTP GET request (instead of a new
> > modified
> > POST) to implement the "DECADE-compatible Remote Get Object"
> message
> > is a good approach.
> >
> >
> >
> > I also like your proposal for the local DECADE server to act as a
> > non-transparent proxy when processing a request from a client.   (I.E.
> > Client makes a request to "DECADE server-1" which then acts as a proxy
> > by forwarding the request to "DECADE server-2").
> >
> >
> >
> > However, I guess this model breaks down if we are required to support
> > a use case where "DECADE server-1" wants to exchange content with
> > "DECADE server-2" without being triggered by a client.
> >
> >
> >
> > Do you agree?
> >
> >
> >
> > Akbar
> >
> >
> >
> >
> >
> >
> >
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Woundy, Richard
> > Sent: Friday, March 30, 2012 10:37 AM
> > To: [e-mail]
> > Subject: [decade] Remote Get Object Message
> >
> >
> >
> > Folks,
> >
> >
> >
> > In Thursday's session, we discussed how to implement the Remote Get
> > Object message. One proposal is to use HTTP Post with a new
> > X-DECADE-ORIGIN header; another proposal is to define a new HTTP
> > message. See slide 3 of
> > <http://www.ietf.org/proceedings/83/slides/slides-83-decade-4.pdf> and
> <http://tools.ietf.org/html/draft-wang-decade-drp-03#section-8>.
> >
> >
> >
> > My thought (as an individual contributor, not as co-chair) is to use
> > existing HTTP Get headers and leverage the base functionality of an
> > HTTP caching proxy in DECADE. The local "DECADE" server would act as a
> > caching proxy (with additional functionality of course) in order to
> > reach the remote "DECADE" server, and cache the contents of the reply in
> the "DECADE"
> > storage. I have a "non-transparent proxy" behavior in mind, per the
> > definition of "proxy" in RFC 2616
> > (http://tools.ietf.org/html/rfc2616#section-1.3). Also see
> > <http://tools.ietf.org/html/rfc2616#section-13>,
> > <http://tools.ietf.org/html/rfc3040>, and perhaps
> > <http://tools.ietf.org/html/rfc3143> as well.
> >
> >
> >
> > Did we fully explore this possibility? As a co-chair, I can assure you
> > that it would be much better to leverage existing protocols and
> > standards, versus inventing new ones.
> >
> >
> >
> > -- Rich