> Chris Lilley, Computer Graphics Unit writes:
>> The problem is that the accept: types are being ignored, I think.
>Accept types aren't a general answer, which is (I think) why they're
>being generally ignored. See below.
>> When a user switches off inline images, the browser should adjust
>> its list of accepted MIME types to not include any image types.
>No, because I may want to download an external GIF if that's all
>that's on the other end of the link, but I also may not want an HTML
>document (if *that's* what's on the other end of the link) to have
>inlined GIF images. What do I then put in the Accept line?
Ah, we have a misunderstanding. Sorry if I was not clear before.
What I meant was that the browser should clear image types from its accept field
when requesting an html file, when inline images are switched off. It should
certainly have them in the accept field when it is following a link to an
external image. The browser can tell the difference by parsing the link.
In other words, I was suggesting that the browser adjust the accept fields
to be relevant to the current request.
>I don't think the Accept thing was sufficiently thought through. I
>think there has to be some notion of context
Agreed. Now that I have explained myself better, do you agree that the
case-by-case twiddling of the accept fields provides this notion of context - at
least, in the case I was discussing?
> -- e.g., I accept these
>formats as inlined images; I accept these formats as external images
>and other media types;
My proposal covered these two cases
>I may accept these formats (if only just to
>save to local disk and view on another system somewhere else later)
>but prompt me before you go ahead and download the data so I can
>decide on a case-by-case basis.
Fine, and I did not consider these as they were outside the context of what i
was discussing (removing latency caused by multiple gets of inline images).>
>> Browsers should accept (and be able to handle) MIME multipart
>> messages.
>Agreed.
>(I will however point out that HUNDREDS of people have said this in
>the past, and yet no one has implemented it. Classic problem, hm?)
Possibly because there was no particularly good reason to do so before? If
implementing multipart is seen to produce tangible performance benefits, rather
than simply being one of those nice things to have for completeness, people will
be motivated to support it.
I would think that implementation would be greatly aided by existing code for
MIME mailers. There is already code to parcel up multiparts and to split them up
again. HTTP being 8 bit clean there is no need to mess around with base64
encodings and such. It is just a case of a few headers and separators.
Chris Lilley
+-----------------------------------------------------------------------------+
| Technical Author, ITTI Computer Graphics and Visualisation Training Project |
+-----------------------------------------------------------------------------+
| Computer Graphics Unit, | Internet: C.C.Lilley@mcc.ac.uk |
| Manchester Computing Centre, | Janet: C.C.Lilley@uk.ac.mcc |
| Oxford Road, | Voice: +44 61 275 6045 |
| Manchester, UK. M13 9PL | Fax: +44 61 275 6040 |
| <A HREF="http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html">click here</A> |
+-----------------------------------------------------------------------------+