Re: Multipart/mixed for many inline images (was Re: Toward Closure on HTML)

wmperry@indiana.edu (William M. Perry)
Errors-To: listmaster@www0.cern.ch
Date: Fri, 8 Apr 1994 23:01:10 --100
Message-id: <m0ppMep-000029C@monolith>
Errors-To: listmaster@www0.cern.ch
Reply-To: wmperry@indiana.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: wmperry@indiana.edu (William M. Perry)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Multipart/mixed for many inline images (was Re: Toward Closure on HTML) 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1472

>-Bill P.(wmperry@indiana.edu) said:
>
>> How should/would one send the multiple requests?  It would not be feasible
>> to say GET url1 url2 url3, as this would interfere with GET url HTTP/1.0.
>
>I did not address this originally because my original post covered a
>different senario. It now seems necessary, because the cost - money cost,
>for the real world - of ignoring cached images is too great and because
>the overhead of parsing the html files on the server side is also a
>drawback.
>
>I was trying to get the HTTP spec to look at, but CERN is down (again) and
>the HENSA cache doesn't have it, currently. Oh well. I was about to find
>an unused character to join the urls with. This is analogous to using +
>for space when sending queries with get.
>
>Lets say & is unused. A possible syntax would be
>
>  GET multi&url1&url2&url3 HTTP/1.1

   Hmmm - I think it would be a bad idea to hardcode something like this
into the standard.  URLs are supposed to be opaque to the client.

>A problem I see with this - is there a max line length for a GET command?

   Depends... there is if you farm out to a shell command (like
/cgi-bin/xxx).  I am not sure if any of the servers have a hardcoded limit
(I seriously doubt it, but you never know).

>Failing which we may be into using POST....

   This would be totally against the 'spirit' of post I believe.

>Sorry about the vagueness, folks; I must print out the spec next time it
>becomes available.

   -Bill P.