Opened 13 years ago

Closed 13 years ago

Last modified 12 years ago

#1081 closed enhancement (wontfix)

add IO type to headers in dojo.io.BrowserIO

Reported by: jkuhnert@… Owned by: James Burke
Priority: high Milestone:
Component: Core Version: 0.3
Keywords: Cc: jkuhnert@…
Blocked By: Blocking:

Description

Probably something that definitely warrents discussion, but it would be nice if the BrowserIO code added headers to the initiating request to give hints to servers on what type of response a request wants.

Currently you have to do some funky things to make sure your server knows how to respond. For instance, in the case of the default ComboBox? DataProvider? - the only option you have is to either replace the data provider or add name/value parameters to the query string.

The mimetype is already checked and known when the request initiates, if they want text/xml, text/javascript, text/json a complimentary header would be pretty easy to add in auto-magically. You wouldn't even need to set an already claimed header...Maybe something like requested-content-type or dojo-content-type...Anything that would allow more "drop in" like functionality for people who have io based widgets/etc.

It's not that much extra data that too many people would make a fuss, but you never know..

Change History (5)

comment:1 Changed 13 years ago by dylan

Owner: changed from anonymous to jkuhnert

comment:2 Changed 13 years ago by jkuhnert

Owner: changed from jkuhnert to James Burke

Re-assigning only to get a general sense of approval, or prompt further questioning if there is any.

According to the http://dojo.jot.com/WikiHome/ModuleExperts page you are the person I should bug before messing with something like this.

comment:3 Changed 13 years ago by James Burke

Hmm, I think I need more convincing. Here are some counter-arguments. Feel free to counter them. :)

  • BrowserIO is only one type of bind transport. All the other transports cannot set HTTP headers. So this would be something specialized for BrowserIO. All of the transports have some specialized restrictions, but if use a querstring/post parameter, that would work for ScriptSrcTransport? and IframeTransport?.
  • I'm not liking adding a custom HTTP header for every BrowserIO request. If the answer is "allow a flag to be passed in to enable it", then I would just prefer that the "flag" is the actual header to send.
  • I know of at least two large API providers (Yahoo and AOL) that use a querystring/post parameter to specify the return format. They happen to use different values for the name of that parameter, so I don't think a name could be chosen that would work for all data services (this is also a concern for choosing an HTTP header name).

comment:4 Changed 13 years ago by jkuhnert

Resolution: wontfix
Status: newclosed

Sounds like a reasonable counter argument to me :) I had a feeling this wasn't the greatest idea in the world so I won't put up much fuss about it.

Closing it out.

comment:5 Changed 12 years ago by (none)

Milestone: 0.4

Milestone 0.4 deleted

Note: See TracTickets for help on using tickets.