Re: Multipart/mixed for many inline images (was Re: Toward Closure on HTML) email@example.com (William M. Perry)
Date: Fri, 8 Apr 1994 23:01:10 --100
From: firstname.lastname@example.org (William M. Perry)
To: Multiple recipients of list <email@example.com>
Subject: Re: Multipart/mixed for many inline images (was Re: Toward Closure on HTML)
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
>-Bill P.(firstname.lastname@example.org) 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
>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