Re: [Lynx-dev] XHTML thwarting

[David Woolley]

> I think he's complaining that it doesn't show _xml_ source.  The missing
> "aha!" here is that the _server_ is sending different pages, according
> to the wishes of the browsers.  Opera tells it that "application/xml" is
> an acceptable data type; Lynx doesn't.  The source sent to Lynx is
> "text/html" because that's what Lynx offers to parse.

Which is correct behaviour for both the server and lynx.  A lot of people
serve XHTML/1.0 when they actually intend it to be viewed by Internet
Explorer, which can only handle XML as a raw parse tree.  Although there is
a so called compatibility subset of XHTML/1.0, it really relies on 
particular error recovery behaviour in browsers and it is much better to
send HTML 4.01 instead.  You can always send HTML 4.01 with all the optional
opening and closing tags explicitly present, so the argument about XHTML
always having all the tags doesn't really hold water (some early HTML 
browsers don't actually work properly when some of the optional closing
tags are present, but that's an issue for the XHTML compatibility subset,
as well).  In any case, when served as HTML browsers no longer enforce 
well-formedness constraints, so missing tags would probably be inserted,
and IE certainly will fix up invalid XHTML (in terms of fixing up the
HTML errors in excess of those due to it being XHTML).

It's correct behaviour for Lynx, as Lynx doesn't, as far as I know, support
XHTML either, except in error recovery mode.

A better tool for downloading arbitrary resources is wget.