> |>> It is important to distinguish two cases :-
> |>>
> |>> 1) Loading all data segments associated with an object (eg html + inline
> |> images)
> |>>
> |>> 2) Contiuous mode connection for realtime response.
> |>>
> |>>
> |>> 1 is solved best through use of MIME multipart type. The browser does a
> |> request
> |>> and gets back the complete object as a single document, inline images and all.
> |>> This is currently being added to the library but slowly :-(
> |>
> |>This is a terrible way to solve that problem. Being able to serve and
> |>handle MIME multipart type objects is a good thing, but it should not be
> |>used to pre-package all inline images.
>
> I think that this misses the point. We are used to having this idea of images
> being separate from the text only because that is the way our tools are
> oriented. What I was suggesting is that in many cases there are texts that
> have a direct relationship to an image and to have one without the other is
> pointless. For example an art gallery where each image has a descriptive text.
While it is true that some documents are like that (and thus being able to
handle MIME multipart type objects is a good thing), the fact is that most
inline images are document-independent (company logos, up, next, prev arrows,
mail box icons, stupid colored dots, etc.) which may be associated with many
different documents on a server. Using multipart to package these would be
a disaster.
> We have to handle multipart soon because the mail viewer should do mime.
I agree.
> The reason why inline images can be cached so well at the moment is that
> in the
> most part they are abused. They add no semantic content, just look pretty
> and are liberaly spread about the place just in case you missed them the
> first time.
True, but I don't think that will change any time soon (or at least not
until we add their semantic equivalents to HTML). I am certain that
people will always use logos as document headers.
> The idea of prepackaging a multiformat document as a mime is not appropriate
> if the inline images are merely icons that are regularly reused. In other
> cases prepackaging is appropriate. Only the author can really tell.
This is still not necessarily the case. An image may be used by any number
of documents, regardless of whether or not the original author knows it is
being used that way. Although this might be an interesting method of
preventing people from reusing your images, it is still a bad idea in general.
>...
> Of course the original author can know this in many cases but not every case.
> So if the author does not know they do not encapsulate.
And how are you supposed to know if I decide to create a local HTML document
which uses inline images from CERN? Similarly, if you change the text of a
document, but not the image, why should a cache-refresh be necessary for both?
> |>> I want to have
> |>>
> |>> GET /path/ http/1.0
> |>> Relative-URI: fred.html
> |>> Relative-URL: jim.html
> |>
> |>I don't like the idea of using headers to indicate something that is
> |>clearly a different method. I particularly don't like those two because
> |>they fail to indicate their purpose. I would much prefer an "MGET" method
> |>which can operate on a list of URIs or include that list as request content,
> |>e.g.
> |>
> |> MGET <uri>.mget HTTP/1.1
>
> This would mean very long method lines which would break many servers.
No, <uri>.mget is just a single URI -- the list would be contained within
the object pointed to by that URI.
> Plus
> there is no real difference between a single get and a multiple get. The
> operation is on a different object, that is all. It is on a composite object
> that is the sum of all the parts.
That's a pretty major difference in my book. What you are talking about
is a different method, and thus I would agree with Martijn's comments.
> |>As for security issues, I am increasingly convinced that they belong in
> |>an entirely separate protocol -- one that may be initiated by an HTTP
> |>request, but only confirmed and maintained via a non-HTTP session.
>
> HTTP without security is not much use. Security objects are no different
> from any other, they can be refered to by URL or URN. They can be retreived.
? HTTP is quite useful without any notion of security in the protocol.
Now, there is no reason why the content can't be (somewhat) more secure
(e.g. encrypted), but that has little to do with HTTP. True security requires
a secure connection, and if you are going to do that, there is no reason to
use HTTP (a stateless protocol which passes rfc822/MIME messages around)
when it is far more efficient to use a stateful, binary (or ASN.1) protocol
that passes compressed and encrypted messages.
However, that is just my opinion. Since I don't use secure services with
WWW, I have no need for security features in HTTP. I would still like to
see how others would implement such a system -- just don't call it HTTP
until a proven implementation exists which acts like HTTP. It is my
"intuition" that no stateless protocol which passes rfc822/MIME messages
around can be truly secure, so why not separate the two needs into two
different protocols?
.....Roy Fielding ICS Grad Student, University of California, Irvine USA
<fielding@ics.uci.edu>
<URL:http://www.ics.uci.edu/dir/grad/Software/fielding>