- From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
- Date: Tue, 21 May 1996 18:41:28 -0500 (EST)
- To: brian@organic.com
- Cc: www-html@w3.org
Brian Behlendorf <brian@organic.com> wrote: >[...] If it's a text-only browser, the author could generate (to >their liking/quality control) a text equivalent. Of course, with Lynx >2.5 claiming to "Accept:" a bunch of image formats this is something of a >problem. [...] Lynx has always sent Accept: headers for images and other binaries. which can be configured to spawn a helper app, else will invoke a download offer. That has been considered preferable to getting back "your client does not support ..." messages from servers. The current Lynx code, scheduled for release, probably, next month as Lynx2-5-1, supports appending of q=qvalue and mxb=maxbytes for content negotiation via Accept headers, a la the Holtman ID. Unfortunately, content negotiation was not included in the HTTP/1.1 ID, and if the q and mxb parameters are included with the Content-Types in Accept headers sent to servers which do not parse out the parameters, you're back to "your client does not support ..." messages from such servers. That's "something of a problem", and so their inclusion is configurable, but not yet recommended. You have one of the infinitely small number of servers which return something useful for text clients, instead of an error message, if no coordinates are appended to requests via server-side image map links. Do you per chance have a server via which Lynx's content negotiation support can be used? Or is it still something of a problem for *all* presently deployed servers? Fote ========================================================================= Foteos Macrides Worcester Foundation for Biomedical Research MACRIDES@SCI.WFBR.EDU 222 Maple Avenue, Shrewsbury, MA 01545 =========================================================================
Received on Tuesday, 21 May 1996 18:41:32 UTC