Re: Multipart response support

Henrik Dvergsdal wrote:
>> 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.
I knew of MIME, but wasn't seeing how it applied. Now I do. Thanks.
> 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"/>
So this is a lot like Microsoft's MHT files produced via a Save As in 
IE.  I could see where that would be useful for storing/archiving a 
document, and it would be nice to have a standard format that Firefox, 
Opera, Safari, et. al. would understand as I use IE for that feature. 
But I could see it wreaking havoc if used on the open Internet by 
website developers who can't be bothered to learn about HTTP, caching, 
and so on.
> 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.
I personally think this would be a really bad thing. Providing 
protections like this will encourage people to be less open and will 
disempower use-cases like search engines.
> * Preloading. Developers can embed critical (small sized) components 
> of pages/applications to ensure that they are up-to-date and 
> immediately available.
This might be good, but can also be very bad if misused as would be 
likely given the education that would be required.  For example, web 
developers might niavely embed a logo to ensure it is always there, but 
now the user downloading 10 pages has to download it 10 times instead of 
once if it were cached.
> * 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.
I can't see how converting a binary to text would make it easier to 
manage.  One search & replace error and they have ruined the binary 
content. It would make more sense for text content, but you can already 
do using another mechanism with Javascript and CSS.
> The discussion so far has revealed some issues that need to be resolved:
>
> * Caching issues
>
> * Ethics of providing mechanisms to protect/hide content on web pages
>
> * Practical value in terms of protecting/hiding
>
> * Practical value in terms of preloading
>
> * Cost of implementation
Agreed there. I'd add "out of scope for the HTML WG" to that list. I 
think there would be some validity for archiving pages, but I think it 
should be done in its own spec.

JMTCWA.

-- 
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org - http://t.oolicio.us
"It never ceases to amaze how many people will proactively debate away attempts to improve the web..."

Received on Thursday, 29 March 2007 15:52:19 UTC