[proposal] add “header” to reponse structure

[humbroll]

There are five HTTP methods in gadget(core) specification(http://
code.google.com/apis/opensocial/docs/0.7/reference/
gadgets.io.MethodType.html): delete, get, head, post and put.
How can I read response ? there is no comment about it.
So, I want to propose to add ‘headers’ parameter to response
structure(http://code.google.com/apis/opensocial/articles/
makerequest.html#programming-response) like below

{
data:…,
errors:…,
text: …,
headers: { Content-Type: “…” , …}
}

gadget code will...

var params = {}
params[gadgets.io.RequestParameters.METHOD] =
gadgets.io.MethodType.HEAD;

gadgets.io.makeRequest(url, function(response) {
if(response.headers.Content-Type.match(/jpeg/)){
alert("it's jpg!");
}
}, params);

Thanks.

[Kevin Brown]

What are the actual use cases for this? You can already return a structured response (JSON or XML). The response headers may or may not be altered by any number of intermediate proxies and caches, and most of the header data is meaningless cruft that would slow the http response.

[humbroll]

What im saying is how can i read headers data when i specify
"params[gadgets.io.RequestParameters.METHOD] =
gadgets.io.MethodType.HEAD;"

Let's say if i want just read content-type in headers, not response
body.
it will be better.

thanks.

On 5월20일, 오후8시31분, "Kevin Brown" <e...@google.com> wrote:
> What are the actual use cases for this? You can already return a structured
> response (JSON or XML). The response headers may or may not be altered by
> any number of intermediate proxies and caches, and most of the header data
> is meaningless cruft that would slow the http response.
>

> On Tue, May 20, 2008 at 4:08 AM, humbroll <humbr...@gmail.com> wrote:
>
> > There are five HTTP methods in gadget(core) specification(http://
> > code.google.com/apis/opensocial/docs/0.7/reference/
> > gadgets.io.MethodType.html): delete, get, head, post and put.
> > How can I read response ? there is no comment about it.
> > So, I want to propose to add 'headers' parameter to response
> > structure(http://code.google.com/apis/opensocial/articles/

> > makerequest.html#programming-response<http://code.google.com/apis/opensocial/articles/makerequest.html#prog...>)

[humbroll]

Let's say if there is gadget to create activity with media item. User
have to write not mime-type(IMAGE | AUDIO | VIDEO), but also media
item's URL.
If i can read content-type in headers, user just insert media item
URL.
Gadget code will like below...

//user inserted media item url
var mediaItemUrl = document.getElementById('m_url').value;
var contentType = null;
var type = null;

var params = {}
params[gadgets.io.RequestParameters.METHOD] =
gadgets.io.MethodType.HEAD;

gadgets.io.makeRequest(mediaItemUrl, function(response) {
contentType = response.headers.Content-Type;
}, params);

if(contentType.match(/jpeg|gif/)){
type = opensocial.Activity.MediaItem.Type.IMAGE;
}else if(response.headers.Content-Type.match(/audio/)){
type = opensocial.Activity.MediaItem.Type.AUDIO;
}else{
type = opensocial.Activity.MediaItem.Type.ViDEO;
}
miParams[opensocial.Activity.MediaItem.Field.TYPE] = type;
var mediaItem = new Array(opensocial.newActivityMediaItem(contentType,
mediaItemUrl));
activityParams[opensocial.Activity.Field.MEDIA_ITEMS] = mediaItem;
var activity = opensocial.newActivity(activityParams);
opensocial.requestCreateActivity(activity, "HIGH", callbackStuff);


thanks.

[John Panzer]

Headers are needed in many situations, including auth
(www-authenticate), atompub resource creation (location:), content
negotiation (did I get plain text or HTML? Don't guess!)

They are really important; we need to provide access to them.

On 5/20/08, Kevin Brown <et...@google.com> wrote:
> What are the actual use cases for this? You can already return a structured
> response (JSON or XML). The response headers may or may not be altered by
> any number of intermediate proxies and caches, and most of the header data
> is meaningless cruft that would slow the http response.
>
> On Tue, May 20, 2008 at 4:08 AM, humbroll <humb...@gmail.com> wrote:
>
>>
>> There are five HTTP methods in gadget(core) specification(http://
>> code.google.com/apis/opensocial/docs/0.7/reference/
>> gadgets.io.MethodType.html): delete, get, head, post and put.
>> How can I read response ? there is no comment about it.
>> So, I want to propose to add 'headers' parameter to response
>> structure(http://code.google.com/apis/opensocial/articles/

>> makerequest.html#programming-response<http://code.google.com/apis/opensocial/articles/makerequest.html#programming-response>)

[Kevin Brown]

On Tue, May 20, 2008 at 10:57 PM, John Panzer <jpa...@google.com> wrote:

Headers are needed in many situations, including auth
(www-authenticate), atompub resource creation (location:), content
negotiation (did I get plain text or HTML? Don't guess!)

They are really important; we need to provide access to them.

In "normal" HTTP this is true, but it's very difficult to make guarantees of the header validity through makeRequest. Requiring proper headers being returned severely limits the flexibility of containers to optimize these calls by caching.

There are also many headers that simply wouldn't be accurate, such as Content-Type (the proxy will usually change the encoding for text-based protocols), Content-Length, Connection, Date, Last-Modified, etc.

Would the following work?

- Return a white list-checked (in the spec) of standard HTTP headers. Containers are free to munge others.
- Return a black list-checked (not in the spec) of X- prefixed HTTP headers. Containers may limit certain X- headers from being returned that they use internally, but should allow all others.

This is similar to the proposal that Brian Eaton had for security in proxy handling in Shindig.

[John Panzer]

On Wed, May 21, 2008 at 11:18 AM, Kevin Brown <et...@google.com> wrote:

On Tue, May 20, 2008 at 10:57 PM, John Panzer <jpa...@google.com> wrote:

Headers are needed in many situations, including auth
(www-authenticate), atompub resource creation (location:), content
negotiation (did I get plain text or HTML? Don't guess!)

They are really important; we need to provide access to them.

In "normal" HTTP this is true, but it's very difficult to make guarantees of the header validity through makeRequest. Requiring proper headers being returned severely limits the flexibility of containers to optimize these calls by caching.

There are also many headers that simply wouldn't be accurate, such as Content-Type (the proxy will usually change the encoding for text-based protocols), Content-Length, Connection, Date, Last-Modified, etc.

I may be misunderstanding the issues, but I'm not understanding how the proxy can not get these correct.

If the proxy changes the encoding, it BETTER set the correct Content-Type header.  How are you supposed to know what encoding you're getting otherwise?  (And if it always changes to the same encoding no matter what, then providing the right Content-Type is clearly trivial, right?)

Content-Length -- kind of important, especially for keep-alive connections going through the browser.  Doesn't the proxy kind of have to get this right if it ever hopes to avoid re-creating TCP connections for each HTTP request?

Last-Modified is easy:  Don't touch it. 


 

[John Panzer]

On Wed, May 21, 2008 at 11:18 AM, Kevin Brown <et...@google.com> wrote:

On Tue, May 20, 2008 at 10:57 PM, John Panzer <jpa...@google.com> wrote:

Headers are needed in many situations, including auth
(www-authenticate), atompub resource creation (location:), content
negotiation (did I get plain text or HTML? Don't guess!)

They are really important; we need to provide access to them.

In "normal" HTTP this is true, but it's very difficult to make guarantees of the header validity through makeRequest. Requiring proper headers being returned severely limits the flexibility of containers to optimize these calls by caching.

Can you provide an example?  (Having worked with Akamai and AOL's shared proxy caching system, both of which stretch specs a bit, but both of which provide return headers without discernible problems, I'm skeptical, but willing to be convinced.)
 

[Kevin Brown]

On Fri, May 23, 2008 at 11:17 PM, John Panzer <jpa...@google.com> wrote:

On Wed, May 21, 2008 at 11:18 AM, Kevin Brown <et...@google.com> wrote:

On Tue, May 20, 2008 at 10:57 PM, John Panzer <jpa...@google.com> wrote:

Headers are needed in many situations, including auth
(www-authenticate), atompub resource creation (location:), content
negotiation (did I get plain text or HTML? Don't guess!)

They are really important; we need to provide access to them.

In "normal" HTTP this is true, but it's very difficult to make guarantees of the header validity through makeRequest. Requiring proper headers being returned severely limits the flexibility of containers to optimize these calls by caching.

There are also many headers that simply wouldn't be accurate, such as Content-Type (the proxy will usually change the encoding for text-based protocols), Content-Length, Connection, Date, Last-Modified, etc.

I may be misunderstanding the issues, but I'm not understanding how the proxy can not get these correct.

If the proxy changes the encoding, it BETTER set the correct Content-Type header.  How are you supposed to know what encoding you're getting otherwise?  (And if it always changes to the same encoding no matter what, then providing the right Content-Type is clearly trivial, right?)

The Content-Type coming back from makeRequest is usually text/plain (or text/json or something along those lines) in all cases. The only guarantee that can be made is that it will be one of the requested types (gadgets.io.ContentType). The original responses content-type can be preserved in some very limited cases (text-based).

If you performed a makeRequest call to an image url, what you'd get back today on all containers I've tested is either an error or a bunch of mangled binary data (usually because the container attempted to convert the data to a unicode string).

HEAD requests could provide accurate Content-Type, however no containers seem to actually support HEAD (and they're not required to support anything other than GET and POST).

Content-Length -- kind of important, especially for keep-alive connections going through the browser.  Doesn't the proxy kind of have to get this right if it ever hopes to avoid re-creating TCP connections for each HTTP request?

The keep alive in this case is to the container, not to the target site. It has no value for the gadget developer; Content-Length will always be the same as the actual length of the payload that they receive in the makeRequest callback, since makeRequest can only handle text-based formats.

Last-Modified is easy:  Don't touch it. 

The caching headers are all going to be modified and rewritten at the container's discretion (as specified in 1.i of http://sites.google.com/a/opensocial.org/opensocial/Technical-Resources/opensocial-spec-v07/gadgets-spec). No guarantees for these values can be made to developers.