- From: Thomas Broyer <t.broyer@gmail.com>
- Date: Tue, 18 Nov 2008 10:18:17 +0100
On Mon, Nov 17, 2008 at 6:31 PM, <mike at mykanjo.co.uk> wrote: > > Would the sender of that link necessarily know all the formats the URL > > provides? Anyway, that's an unrealistic amount of typing -- typically > > round here people just copy and paste a URL into an instant message > > and send it without any surrounding text. > > > > Whereas without any other information, people will generally open URLs > > in a web browser. So it'd be faster just to send the URL of the page > > which contains hypertext links to all the formats; at which point we no > > longer care whether those links specify the format in the URL or > > elsewhere. > > - The HTML version of that URL could provide the web page representation > *and* provide links to all the other content types available. How about other representations? (I know we're discussing HTML here, and not HTTP, but what if a resource has no HTML representation? are you proposing adding this capability to PDF, MSOffice, OpenDocument, et al. too?) > > What is the point of doing it in HTTP if it's being done in HTML anyway? > > - Nothing is 'done' in HTML, it's a markup language. It's being done (at the > moment) in the URI. HTTP provides conneg, why would you consciously > deny developers the opportunity to use it in browsers? Unless HTML5 > provides the markup, this isn't possible. This means Browsers don't have > the ability to fully support HTTP without having to use JavaScript rubbish; > there is a window of opportunity to change this with HTML5. No. Browsers fully support HTTP in the sense that they send an Accept header dependent of their *capabilities*. If you want client-driven conneg, then use agent-driven/transparent (RFCs 2295/2296), not server-driven conneg. This is explicitly noted in RFC 2616 that server-driven negotiation has limits and can be disadvantageous depending on your needs. http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html#sec12 > > True. But if the current way of doing it is good enough, there's no > > incentive to change." > > - Define 'enough'..! I don't know why/how you get the authority to > make that assumption! And before you say it; I'm not assuming any > authority myself - I'm trying to encourage you to help browsers conform > to the protocol they make use of. Maybe you could explain how browsers do not conform to HTTP? (and no, HTTP does not mandate user-agents to give the control of the Accept-* headers to the user or the... server?!) There's an extension to HTTP (TCN/RSVA, RFCs 2295/2296) that gives the servers the ability to describe the available variants of a given resource in a content-type independent way. You'd rather push browser vendors to implement TCN/RSVA than HTML5 to add a content-type dependent equivalent. See also http://docs.google.com/View?docid=dggq7g95_10cd8zj5 > - I'll say it again: I'm encouraging you to help browsers become > better HTTP clients; surely that is high on the agenda here.. right?! No, we're discussing HTML and some "Web APIs" here, not HTTP. > > Or what about if I wanted to mail somebody pointing out a discrepency > > between two versions of the report, and wished to link to both of them. > > That's tricky if they have the same URL. Possibly I could do it like > > you have with the wget command-line above, but that requires me knowing > > which browsers my audience use and the precise syntax for them." > > - separate versions are separate resources, not separate content types. That > has nothing to do with conneg.. s/version/variant/ Variants still need be produced by someone or something, and there really might be discrepencies between them; that's why there's a "quality" parameter in TCN/RSVA (and thus in Apache type-map files, for instance) -- Thomas Broyer
Received on Tuesday, 18 November 2008 01:18:17 UTC