- From: Sandro Hawke <sandro@w3.org>
- Date: Mon, 08 Dec 2003 07:23:46 -0500
- To: Patrick Stickler <patrick.stickler@nokia.com>
- Cc: "ext Seairth Jacobs" <seairth@seairth.com>, www-tag@w3.org
> > So what if the feed must be be accessed over HTTPS? Do we then also
> > need a "feeds" scheme?
>
> This is why the new-URI approach seems to go against the grain
> of the current web architecture.
>
> What is needed here is pretty simple. The browser needs to be
> extended so that it recognizes two (or more) kinds of integration
> with helper applications, given a particular MIME type:
>
> 1. pass the content of the response to the helper application
> 2. pass the entire reponse, headers and all, to the helper application
>
> For #2, it could insert the original request URI into the response
> header, in case the helper application prefers that to the URI
> denoting the response.
>
> In either case, no need to get entagled with http vs https, etc.
>
> I.e., as Norman suggested, just make the browser and handler
> "do the right thing". No need for new URI schemes or handling
> semantics here.
Just make the server include all the necessary information
(subscription instructions) in the response body. It seems to me,
looking at the semantics of the situation, that's the right thing to
do anyway.
No need to hack the browser at all.
(Although I still think doing this kind of thing from an aggregator
makes more sense, anyway.)
-- sandro
Received on Monday, 8 December 2003 07:23:53 UTC