Re: Faster HTTP Was:Re: The Superhighway Steamroller

Marc VanHeyningen (
Thu, 7 Jul 1994 18:45:51 +0200

Phil Hallam-Baker sed:
>I perl:
>|>Phil Hallam-Baker sed:
>|>>OK so this >Looks< like we have an extra connection per transaction. Quelle
>|>>horreur! In fact we cache the page - cleverly in parsed form. So we only do
>|>>one extra GET and one parse for the accept group each time the server comes
> up
>|>Of course, the precise Accept: header will be different not just for
>|>each browser, but for each different mailcap (or other similar
>|>configuration) file; i.e. it will be different for each site, and
>|>plausibly different for each user. This means the browser needs to be
>|>able to somehow create a document which specifies its current accept
>|>status, which is possible but far from trivial or universal, and
>|>caching will have limited benefit.
>If you have a different accept header then you are most likely to be adding
>extra accepts in rather than subtracting (Yuk! I don't want Gifs ... ?).

Yuk! I have a really slow floating-point, so I want to decrease the
preferability settings for JPEGs (assuming servers or clients come out
to support this anytime soon. :-) This doesn't necessarily have to be
a problem, though.

>I don't think we should get hung up about the 5% or 1% of cases which are
>different. Nobody is suggesting getting rid of Accept headers altogether.
>Its just an optimisation that can be applied for a large number of cases.

Just so I have a better idea of this, could you show me what the
default set of Accept: headers for the linemode browser would look
like? It supports text/html and text/plain natively (big deal, don't
even need to declare that) and can handle application/octet-stream
(save it to a file.) What else would go in there? The ubiquitious

Mosaic, similarly, handles few types natively; those above, plus
image/gif if it's in the context of inlined images (another domain
where the accepts should be different.)

>In general I would like to suggest a principle that *ALL* areas where there
>is a degree of flexibility should be referenced via URLs. If we tried to
>compress accept groups in a static manner then there would always be a problem
>when new accept groups were declared. URLs allow us to deffer the specificatio
>and more importantly distribute it.

This seems a reasonable approach in general; I just am not sure how
much it will help with this particular application.

<A HREF="">Marc VanHeyningen</A>