--- "A. Pagaltzis" <[EMAIL PROTECTED]> wrote: > * John Napiorkowski <[EMAIL PROTECTED]> [2006-11-29 > 00:05]: > > I often find that the resource of a given URI can > have > > alternative formats. For example, I might have a > table of > > information on an html webpage and I want to offer > two > > alternative representations, a comma separated > version and an > > ATOM feed. > > Itâs not ATOM, any more than Perl is PERL. :-) > Itâs just Atom. > The name doesnât stand for anything. > > > So, what are you all doing to handle this? Has > the 'cool urls > > don't have file extensions' school of though > fallen out of > > favor? Has someone found a better way, or a > compelling reason > > to choose one over the other? > > HTTP has had an answer for this for a long time, > although it > hasnât seen much use. (Just like a lot of HTTP in > generalâ¦) Itâs > called Content Negotiation and revolves around the > Accept header. > > HTTP in general has a three-pronged architecture: > URIs, resources > and representations. URIs identify resources, but > each resource > can have multiple representations. Clients can use > the Accept > header on a request to supply a list of MIME types > they > understand, complete with a preference ranking. The > server can > use this to decide which representation of the > resource it will > serve. > > In practice, conneg (content negotiation) suffers > from both > conceptual problems and neglect. The conceptual > problem is that > that he resource/representation duality is often > fuzzy, and > conneg makes it harder to use the main cornerstone > of web > architecture, ie. identify specific things by URI, > which is > a powerful concept. > > My current thinking on how to handle things is based > on the fact > that the form of response to a request with conneg > is entirely at > the serverâs discretion. So I think this makes the > most sense: > > ⢠The resource is identified by > <http://example.org/foo>. > > ⢠Requests with (explicit or implicit) `Accept: *` > directly > return the default representation in the body of a > 200 OK > response. > > ⢠Requests with a more restrictive Accept header > which the server > deems it can serve are answered with a 302 > redirect. > > ⢠Such redirects go to > <http://example.org/foo.ext>. > > ⢠If a request to <http://example.org/foo.ext> has > an Accept > header that precludes the media type of that > particular > representation, the server responds 406 Not > Acceptable. > > An open question I have is whether requests to > <http://example.org/foo.ext> with `Accept: *` should > actually > serve the resource or redirect back to > <http://example.org/foo> > â which would mean that unless you insist on a GIF > image when you > ask for <http://example.org/foo.gif>, you might > actually get > a PNG image from <http://example.org/foo>. Yeah, it > sounds crazy, > but the issue at hand is âcanonical URIs.â Eg. I > donât want > a search engine spider to index my content thrice, > just because > I offer it as all of text/plain, text/html and > application/xhtml+xml. > > Mind you, this is not at all practice-proofed. > Itâs just my > current hypothesis as to the probably best approach > to handle > this.
This seems like a good approach. I was suffering for the content negotiation issue since it seemed all the user agents are very loose when it comes to this. For example when I do something like: <link rel="stylesheet" type="text/css" .... /> It seems that the browser doesn't generate a request with a content type restricted to text/css, which is rather unfortunate. Also there are really stupid user agents that need the extension. For example I have an application that embeds some flash video. Now this uses the video component that is part of flash 8 or something and it seems to absolutely require that the file name of the flash video be "something.flv". Even if I set the content type to video/x-flv which is what the documents say, and I specify a filename in the content disposition unless that file has flv at the end it just won't play. So unfortunately we need to deal with this, but also set things up right so that when the user agents get smarter we are already set up for it. --john > > I decided for the /foo.ext rather than the > /foo?format=ext > approach because thereâs no difference in > information conveyed > between the two. > > Regards, > -- > Aristotle Pagaltzis // <http://plasmasturm.org/> > > _______________________________________________ > List: [email protected] > Listinfo: > http://lists.rawmode.org/mailman/listinfo/catalyst > Searchable archive: > http://www.mail-archive.com/[email protected]/ > Dev site: http://dev.catalyst.perl.org/ > ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com _______________________________________________ List: [email protected] Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
