W3C home > Mailing lists > Public > public-html@w3.org > March 2007

Re: Multipart response support

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 29 Mar 2007 12:27:47 +0200
Message-ID: <460B94A3.3030905@gmx.de>
To: Henrik Dvergsdal <henrik.dvergsdal@hibo.no>
CC: public-html@w3.org

Henrik Dvergsdal schrieb:
>> Can you please define what exactly you mean by multipart responses in 
>> HTML?  Everyone who has responded seems to understand but I still 
>> can't derive your meaning from the context.  Ideally, can you also 
>> provide a short little example?
> There is an article in wikipedia that explains the basic concepts:
> http://en.wikipedia.org/wiki/MIME
> HTML currently supports the MIME type multipart/form-data in HTTP 
> requests. This is primarily used to upload files.
> What I suggest is  to add support for the MIME type multipart/related 
> (or perhaps multipart/mixed) in HTTP *response* messages.

But that's not an HTML feature, but a browser feature. IE already 
supports it, and the spec is at <http://tools.ietf.org/html/rfc2387>. 
You may want to lobby for an update of that spec, and for support in 
Mozilla, but that really isn't something for the HTML WG (imho).

> This would allow inclusion of scripts, stylesheets, media and other 
> types of resources in web pages/applications as attachments in a single 
> response so that they don't have to be downloaded separately.
> Within HTML we would need a syntax for refering to attached resources 
> rather than URL's. Maybe something like this: ... ?
> <img src="attached:apple.jpg"/>

Again. That issue already has been solved.

> Some usage scenarios:
> * Media protection. By embedding media as attachments, users can raise 
> the barrier towards theft or abuse, especially if they are also provided 
> with mechanisms to disable right-clicking etc. in the client.

Just an additional layer of obscurity. If it's a public resource, it can 
be saved. Live with it.

> * Preloading. Developers can embed critical (small sized) components of 
> pages/applications to ensure that they are up-to-date and immediately 
> available.

You can already do that with "data" URIs. Also, preloading is worse than 
re-using cached content, something you loose with that format.

> * Simplification of server side applications. Developers can manage 
> resources (generated media content, binary data, xml data etc.) within a 
> single application rather than having to create separate applications to 
> generate external downloads.

Can you explain how you need "separate applications" for that?

> ...

Best regards, Julian
Received on Thursday, 29 March 2007 10:28:05 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:21:35 UTC