|>Phil Hallam-Baker sed:
|>>I perl:
|>>|>Phil Hallam-Baker sed:
|>>|>>Accept-URI: http://www.cern.ch/Accept/Linemode
|>>|>>
|>>|>>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.
OK so we need a convention for overriding,
Accept-URI: http://blah
Accept: image/jpeg q=0.0
|>>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
|>*/*?
On my reading of the specs text/html and text/plain have to go in there if
there are any accept headers at all. The default applies only if you specify
no accept headers at all.
http://info.cern.ch/hypertext/WWW/Protocols/HTTP/HTRQ_Headers.html
>If no Accept: field is present, then it is assumed that text/plain and text/html are
>accepted.
OK standard header is:-
GET / HTTP/1.0
Accept: */*; q=0.300
Accept: application/octet-stream; q=0.100
Accept: text/plain
Accept: text/html
User-Agent: CERN-LineMode/2.14 libwww/2.16pre2
This becommeth :-
GET / HTTP/1.0
Accept-URI: http://www.org/Accept/Linemode2.14
User-Agent: CERN-LineMode/2.14 libwww/2.16pre2
Which has in it:-
Accept: */*; q=0.300
Accept: application/octet-stream; q=0.100
Accept: text/plain
Accept: text/html
If you want to compress further you could use a header URI and put the User
Agent line there :-
GET / HTTP/1.0
Header-URI: http://www.org/Accept/Linemode2.14
I prefer Header-URI.
So for a browser running under X11R6 we might expect as a basic set of accepts:-
Accept: */*; q=0.300
Accept: application/octet-stream; q=0.100
Accept: text/plain
Accept: text/html
Accept: text/html+
Accept: text/nroff
Accept: image/jpeg
Accept: image/gif
Accept: image/xbm
Accept: image/pbmp
A single browser might have more than one config file...
Alternatively let us consider the case where a browser is really wierd but
accepts */* with low quality. It asks for a document. 95% of the time the
server only has one format to serve it in anyway. So most of the time the
accept header is ignored completely. In this case it is not a big loss
to specify a deffered header on a non standard server and thus unlikely to
be cached.
The other obvious alternative to speed up the system would be to incorporate
some sort of negotiation protocol. This again can be leveraged. The Header-URI
could be fetched inband in the same connettion :-
GET /blah http/2.0
Header-URI GET://linemode
469 Not likely mate! Switch contexts
GET //linemode
201 OK here you are..
blahh
SWITCH
GET /blah http/2.0
Header-URI GET://linemode
200 Ca va?
blahh .........
|>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.)
I think we will start to see a change in this situation. Clients will
handle most types natively. Why on earth does Mosaic not inline gif files
accesed by URL?
-- Phillip M. Hallam-BakerNot Speaking for anyone else.