[v0.NEXT Proposal] Return response headers from makeRequest() calls

[Randgalt]

This is my first one of these. I apologize in advance if I made
any errors.

* Description *

gadgets.io.makeRequest() does not currently return any of the response
headers to the gadget. This makes it impossible to maintain any data
(i.e. a session) between requests. gadgets.io.makeRequest() currently
supports setting request headers. This proposal is to add an
additional field to the response object called “headers” that contains
an array of well-known response headers.

* Modification to current spec *

I can’t find anywhere in the spec where the response object passed to
the makeRequest() callback is defined. The only language I’ve seen is
here: http://sites.google.com/site/opensocialdraft/Home/gadgets-api-specification
where it says "The makeRequest() callback parameter is passed a
javascript object with several OAuth-specific fields in addition to
the normal values returned."

So, I guess the addition to the spec is:

3.2.3 Processing Response Headers

The container MUST assign an array to the response object called
“headers” that contains an entry for each well-known HTTP response
header returned from the makeRequest() URL. The well-known reponse
headers are, but not limited to:
* server
* set-cookie
* pragma
* date
* server
* expires
* cache-control

* Discussion *

http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/51b016b80e9d21e6?pli=1

[Brian Eaton]

On Thu, Feb 26, 2009 at 10:29 PM, Randgalt <rand...@gmail.com> wrote:
> The container MUST assign an array to the response object called
> “headers” that contains an entry for each well-known HTTP response
> header returned from the makeRequest() URL. The well-known reponse
> headers are, but not limited to:
>  * server
>  * set-cookie
>  * pragma
>  * date
>  * server
>  * expires
>  * cache-control

The only one of those headers that sounds useful is set-cookie. Why
blow up makeRequest response size by returning the others?

[Randgalt]

> The only one of those headers that sounds useful is set-cookie.  Why
> blow up makeRequest response size by returning the others?

I agree that the list may be too big. pragma is very useful for
communicating miscellaneous values. The gadget and server could have a
scheme to include custom values in pragmas. date is useful for
validating time sync between the server and the client. So, I'd trmi
the required set to:

* date
* set-cookie
* pragma

[Randgalt]

I guess no one wants this? Please reply with +1 if you want this
feature.

[Scott Seely]

We have gone down the path of adding more support for apps that are
hosted externally. The proxied content model being introduced in 0.9
should support the scenarios that require session and other factors
related to knowing about the headers. Perhaps Louis or someone else can
comment on that aspect.

I think this is why you are seeing little enthusiasm for this idea.

[Louis Ryan]

Currently Google implementations return set-cookie and location headers for gadgets.io.makeRequest. It would add a fair amount of bloat to include all the headers servers spit out. What would you expect to use things like cache-control, expires and pragma for? Container implementations generally act as standard HTTP proxies and makeRequest is not designed to allow you to do programmatic content invalidation. If you want that see the 'Limited Invalidation' spec for OpenSocial 0.9

-Louis

[Randgalt]

On Mar 3, 9:25 am, Louis Ryan <lr...@google.com> wrote:
> Currently Google implementations return set-cookie and location headers for
> gadgets.io.makeRequest. It would add a fair amount of bloat to include all
> the headers servers spit out. What would you expect to use things like
> cache-control, expires and pragma for?

set-cookie is the most important one. If Google is doing it (Shindig
is as well), why not add it to the spec? If gadgets can't count on the
behavior in any container then it's useless.

[Brian Eaton]

Location and Set-Cookie were added because they were useful for
integration with web services API that use cookies and/or URL
parameters for load balancing. I've seen several APIs (photobucket,
google calendar) that need this kind of support.

Network load balancers have been using cookies and URL parameters for
browser based apps for a while, and the functionality has proven
useful for RPC-over-HTTP type apps.

[Randgalt]

OK - I'll update the proposal then and get some +1s going