XHTML Problems

[Andy Dingley]

Re: XHTML Problems

On Mon, 04 Jul 2005 13:58:51 +0900, Tim <tim@mail.local host.invalid>
wrote:
[color=blue]
>Are one of you talking about filenames, and the other about URIs?[/color]

I'm talking about both. Two sorts of file extension is good, as it
labels the content. Two sorts of extension embedded in the URL is bad,
as it makes link-management messy.

If there's some means of solving both situations (i.e. distinguishing
them when we talk about files, hiding it when we talk about URLs) then
we can avoid these problems.

[color=blue]
>You can
>have both filenames in use (depending on content), and not refer to the
>filename specifically with requests (i.e. sans-suffix).
>
>e.g. Request http://example.com/pagename
> And get pagename.html or pagename.xhtml, depending on what's stored
> on the server, and what suits the browser (should there be a choice).[/color]

My Apache-fu is weak.

Is it practical to do this when there's only one file (.xhtml) and the
browser wants only text/html ? I know the server can choose to serve a
..html file instead of the .xhtml, but AFAIK this would require two
copies of the content on the server.

What I'm looking for is content negotiation that can silently choose to
deliver either XHTML, or Appendix C XHTML-as-HTML, according to browser
acceptance. Is this possible ? Would you happen to have an example of
it that we might learn from ?

[Alan J. Flavell]

Re: XHTML Problems

On Mon, 4 Jul 2005, Andy Dingley wrote:
[color=blue]
> On Mon, 04 Jul 2005 13:58:51 +0900, Tim <tim@mail.local host.invalid>
> wrote:
>[color=green]
> >Are one of you talking about filenames, and the other about URIs?[/color]
>
> I'm talking about both. Two sorts of file extension is good, as it
> labels the content. Two sorts of extension embedded in the URL is
> bad, as it makes link-management messy.[/color]

I'm not sure exactly what that's supposed to mean, but for any reader
who isn't accustomed to your style, may I just stress that in WWW
terms, the content-type of anything retrieved by HTTP is determined by
the HTTP Content-type header, and the file "extension" does not play
any *direct* role in that interworking interface. [Sure, within the
actual server it may very well be that the *server itself* uses the
file "extension" as a way of labelling the content-type; the key
feature is that this is not part of the defined HTTP interworking
interface between the server and the client.] You knew all that, of
course, I'm just worried that some readers might be confused about it,
and perhaps exacerbated by MSIE's violation of RFC2616, and MS's
mischievous citation of RFC2616 in the part of their documentation
where they describe, without admitting it, that they are in violation
of this mandatory requirement.

[...]
[color=blue]
> Is it practical to do this when there's only one file (.xhtml) and
> the browser wants only text/html ? I know the server can choose to
> serve a .html file instead of the .xhtml, but AFAIK this would
> require two copies of the content on the server.[/color]

My experiments with Apache 1.3.* showed that strange things could
sometimes happen with MultiViews, but generally speaking, a symlink
would be sufficient, you wouldn't need literally two copies. If you
work via a type-map file (which could be written programmaticall y, e.g
as part of your publish-to-web process in a makefile), then you can
eliminate even this part of the problem.
[color=blue]
> What I'm looking for is content negotiation that can silently choose
> to deliver either XHTML, or Appendix C XHTML-as-HTML, according to
> browser acceptance.[/color]

I understand you here to mean delivering the same actual file with
different content-type headers as the outcome of content negotiation,
right?
[color=blue]
> Is this possible ?[/color]

It's definitely possible, yes. However, since I wrote the relevant
pages (which were concentrating on language negotiation rather than on
content-type negotiation, but the principle is closely similar), we've
moved our server from Apache 1.3.* to 2.0.*, so I can't offer you a
100% convincing demonstration yet - all that I can offer you is an
assurance that it can be done. As I say, if MultiViews proves
intractable for your purpose (I'm not absolutely sure if this is so or
not), then using a type-map file will, I am convinced, offer a
solution.

http://ppewww.ph.gla.ac.uk/~flavell/www/lang-neg.html

see also http://ppewww.ph.gla.ac.uk/~flavell/...tent-type.html

good luck

[James Pickering]

Re: XHTML Problems

I solicit comments on the following article:

http://insight.zdnet.co.uk/internet/0,39020451,2135615,00.htm

[Steve Pugh]

Re: XHTML Problems

"James Pickering" <jp29@cox.net > wrote:
[color=blue]
>I solicit comments on the following article:
>
>http://insight.zdnet.co.uk/internet/...2135615,00.htm[/color]

Hmm, comments. It's a two year old article and I don't see the
relevance to this thread about XHTML and content-type headers in
general and to Alan's post in particular.

Steve

--
"Grab reality by the balls and squeeze." - Tempus Thales

Steve Pugh <steve@pugh.net > <http://steve.pugh.net/>

[Andy Dingley]

Re: XHTML Problems

On 4 Jul 2005 10:09:11 -0700, "James Pickering" <jp29@cox.net > wrote:
[color=blue]
>I solicit comments on the following article:[/color]

How about "completely irrelevant" ?

[Andy Dingley]

Re: XHTML Problems

On Mon, 4 Jul 2005 17:32:17 +0100, "Alan J. Flavell"
<flavell@ph.gla .ac.uk> wrote:
[color=blue]
>in WWW
>terms, the content-type of anything retrieved by HTTP is determined by
>the HTTP Content-type header, and the file "extension" does not play
>any *direct* role in that interworking interface.[/color]

There's a mapping from characters in the URL to the file extension of
the file selected to supply the content. This isn't part of HTTP, it's
entirely server and server-config dependent. But it happens a lot, we
all do it, and it's the subject of this thread - so I don't want to
pretend that we exist in some vacuum of standards-only behaviour where
the dirty behind-the-scenes stuff just doesn't exist.
[color=blue][color=green]
>> Is it practical to do this when there's only one file (.xhtml) and
>> the browser wants only text/html ?[/color][/color]
[color=blue]
>a symlink would be sufficient, you wouldn't need literally two copies.[/color]

Hmmm - that's in some ways inelegant, but I can see how it would work.
Why should I get my filesystem to tell lies, just to fool a server into
accomplishing what's at heart a server-specific task? What happens if a
filesystem-based CMS task is trying to look and see if an XHTML or HTML
version is available, by using a simple directory listing?

[color=blue]
>I understand you here to mean delivering the same actual file with
>different content-type headers as the outcome of content negotiation,
>right?[/color]

Yes. The _same_ file, if there is no more relevant file (i.e. pure
HTML) available.

[Tim]

Re: XHTML Problems

Tim <tim@mail.local host.invalid> wrote:
[color=blue][color=green]
>> Are one of you talking about filenames, and the other about URIs?[/color][/color]

Andy Dingley <dingbat@codesm iths.com> posted:
[color=blue]
> I'm talking about both. Two sorts of file extension is good, as it
> labels the content.[/color]

Unnecessary, except to the page author. People clicking links don't need
to know whether it's HTML, XHTML, a flat file or dynamically generated,
etc.

It also *doesn't* label the content. You might think that it does, but
it's only a hint at what you might get. I can serve you anything with a
..html suffixed link. And how many of us have tried to right-click and
download some file, seeing a something.exe link, only to end up saving an
HTML page which was a click-through to the download?
[color=blue]
> Two sorts of extension embedded in the URL is bad, as it makes
> link-management messy.[/color]

Unnecessary, again. That's not how it works. Going back to my prior
example, as below. The links are ambiguous.

For now, and evermore, I can offer a link about "configurin g my DNS
software" at <http://example.com/configuring_my_ DNS_software> and everyone
will be able to read it, whether I write it in HTML today, XHTML next
month, or something else in two years time.

There's one link, and the server provides what's needed, behind the scenes.
If I provide just one file, that's all everybody gets (as the requested
URI). If I provide different versions, their browser and my server can
decide what's best. If we can't decide, the browser *can* offer a list of
choices.

I don't ever have to get people to change their bookmarks, re-write
documentation, etc.
[color=blue][color=green]
>> You canhave both filenames in use (depending on content), and not refer
>> to the filename specifically with requests (i.e. sans-suffix).
>>
>> e.g. Request http://example.com/pagename
>> And get pagename.html or pagename.xhtml, depending on what's stored
>> on the server, and what suits the browser (should there be a choice).[/color][/color]
[color=blue]
> My Apache-fu is weak.
>
> Is it practical to do this when there's only one file (.xhtml) and the
> browser wants only text/html ? I know the server can choose to serve a
> .html file instead of the .xhtml, but AFAIK this would require two
> copies of the content on the server.[/color]

Why bother? HTML and XHTML provide the same information to the reader.
Carry on using HTML on existing documents, when you add new documents or
modify old ones, you can make them XHTML, and forget about dual serving.

Personally, I strongly advise against using XHTML. It's just so seriously
broken in the most prevalent client, and the usual daft way of serving it
destroys any benefits of using it with better clients.
[color=blue]
> What I'm looking for is content negotiation that can silently choose to
> deliver either XHTML, or Appendix C XHTML-as-HTML, according to browser
> acceptance. Is this possible ? Would you happen to have an example of
> it that we might learn from ?[/color]

Possible, but why bother. And I can't think of an example, because it's
pointless.

Also, trying to serve one to this and the other to that will fall right
into that age-old recipe for disaster - browser sniffing (something that's
unreliable).

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

[Alan J. Flavell]

Re: XHTML Problems


On Mon, 4 Jul 2005, Andy Dingley wrote:
[color=blue]
> On Mon, 4 Jul 2005 17:32:17 +0100, "Alan J. Flavell"
> <flavell@ph.gla .ac.uk> wrote:
>[color=green]
> >in WWW
> >terms, the content-type of anything retrieved by HTTP is determined by
> >the HTTP Content-type header, and the file "extension" does not play
> >any *direct* role in that interworking interface.[/color]
>
> There's a mapping from characters in the URL to the file extension of
> the file selected to supply the content.[/color]

There can be, and often is, yes, which is why it's IMHO so important to
understand how this fits into the general scheme of things.
[color=blue]
> This isn't part of HTTP, it's entirely server and server-config
> dependent.[/color]

Exactly so. The file "extension" is of no concern to the client, they
*must* (according to rfc2616) go solely on the HTTP content-type when
there is one (and in practice there always is).
[color=blue]
> But it happens a lot, we all do it,[/color]

Sure, many of "us" use file extensions like .cgi and .php to generate HTML
:-}
[color=blue]
> and it's the subject of this thread[/color]

Is it? Anyway, I think this issue *does* need to be stressed, for the
reasons that I gave.
[color=blue]
> - so I don't want to pretend that we exist in some vacuum of
> standards-only behaviour where the dirty behind-the-scenes stuff just
> doesn't exist.[/color]

Now you've lost me. The standards-only behaviour works fine (between the
server and the client), whether the file extension was .htm, .html., .cgi,
..pl or .php (or .asp, for that matter).
[color=blue][color=green][color=darkred]
> >> Is it practical to do this when there's only one file (.xhtml) and
> >> the browser wants only text/html ?[/color][/color]
>[color=green]
> >a symlink would be sufficient, you wouldn't need literally two copies.[/color]
>
> Hmmm - that's in some ways inelegant,[/color]

You've every right to say that, but if you use MultiViews then you do need
some way to tell the server what's what, and that seems to me to be the
way to do it. If, on the other hand, you use a typemap file for
negotiation, then the typemap file can do the job, based on just a single
file with the content in it, as you're requesting. No matter how many
different dimensions of negotiation are involved.
[color=blue]
> Why should I get my filesystem to tell lies, just to fool a server into
> accomplishing what's at heart a server-specific task?[/color]

I can only repeat "see above". And the interaction between the (httpd)
server and the server's file system is purely internal, as noted before:
it has no relevance for the client.
[color=blue]
> What happens if a
> filesystem-based CMS task is trying to look and see if an XHTML or HTML
> version is available, by using a simple directory listing?[/color]

Interesting question, and maybe server dependent.

Give me a while (I have a few pressing problems to solve right now to earn
my crust) and I'll make a test case for this, since I don't seem to have
one yet.
[color=blue][color=green]
> >I understand you here to mean delivering the same actual file with
> >different content-type headers as the outcome of content negotiation,
> >right?[/color]
>
> Yes. The _same_ file, if there is no more relevant file (i.e. pure
> HTML) available.[/color]

Then maybe you would indeed be happier with the type-map approach instead
of MultiViews.

hope this helps

[Alan J. Flavell]

Re: XHTML Problems


On Tue, 5 Jul 2005, Tim wrote:
[color=blue]
> Andy Dingley <dingbat@codesm iths.com> posted:[/color]
[...][color=blue][color=green]
> > What I'm looking for is content negotiation that can silently choose to
> > deliver either XHTML, or Appendix C XHTML-as-HTML, according to browser
> > acceptance. Is this possible ? Would you happen to have an example of
> > it that we might learn from ?[/color]
>
> Possible, but why bother. And I can't think of an example, because it's
> pointless.[/color]

As I say on my cited page, if you implement server-side negotation then I
would recommend also implementing some other way of getting to the
content. Server-side negotiation works fine in properly-configured
web-compatible browsers, but many users will be using something that fails
one or both of those criteria.

http://ppewww.ph.gla.ac.uk/~flavell/www/lang-neg.html

[color=blue]
> Also, trying to serve one to this and the other to that will fall right
> into that age-old recipe for disaster - browser sniffing[/color]

No, it won't. Server-side negotiation does no such thing. Quite the
opposite, in fact, since making the user-agent string a dimension of
negotation is completely impractical and useless, I don't recall anyone
ever seriously suggesting it even, let alone implementing it.

Of course MSIE doesn't implement anything that could be useful for
server-side negotiation (quite the opposite in fact), but it rules itself
out as a web-compatible browser in so many other ways too. If you follow
the advice to implement some alternative way of accessing the content,
this need not be a specific problem.

You're entitled to your views on the pointlessness of serving XHTML under
the provisions of Appendix C (in fact I rather sympathise with those views
myself), but that should be argued as an issue in its own right, and it in
no way discredits the idea of server-side negotiation as such.

[Tim]

Re: XHTML Problems

Andy Dingley <dingbat@codesm iths.com> posted:
[color=blue][color=green][color=darkred]
>>> What I'm looking for is content negotiation that can silently choose to
>>> deliver either XHTML, or Appendix C XHTML-as-HTML, according to browser
>>> acceptance. Is this possible ? Would you happen to have an example of
>>> it that we might learn from ?[/color][/color][/color]

Tim wrote:
[color=blue][color=green]
>> Possible, but why bother. And I can't think of an example, because it's
>> pointless.[/color][/color]

"Alan J. Flavell" <flavell@physic s.gla.ac.uk> posted:
[color=blue]
> As I say on my cited page, if you implement server-side negotation then I
> would recommend also implementing some other way of getting to the
> content. Server-side negotiation works fine in properly-configured
> web-compatible browsers, but many users will be using something that fails
> one or both of those criteria.
>
> http://ppewww.ph.gla.ac.uk/~flavell/www/lang-neg.html[/color]

I mean, I couldn't see the point in serving the same XHTML page with one
MIME type or another based on some presumption that one will do the job
better than the other. I can't see the point in doing *that* both ways.

I also wouldn't care for the extra issues involved in trying to make sure
that you do it right.
[color=blue][color=green]
>> Also, trying to serve one to this and the other to that will fall right
>> into that age-old recipe for disaster - browser sniffing[/color][/color]
[color=blue]
> No, it won't. Server-side negotiation does no such thing. Quite the
> opposite, in fact, since making the user-agent string a dimension of
> negotation is completely impractical and useless, I don't recall anyone
> ever seriously suggesting it even, let alone implementing it.
>
> Of course MSIE doesn't implement anything that could be useful for
> server-side negotiation (quite the opposite in fact), but it rules itself
> out as a web-compatible browser in so many other ways too. If you follow
> the advice to implement some alternative way of accessing the content,
> this need not be a specific problem.[/color]

Which is what I was getting at. If I were to try and either server XHTML
as XHTML, or fake it as HTML, I can't rely on a browser saying it can
handle it or not (because some just lie). So, the usual stupid trick is
for the webmaster (sneer) to decide that this browser can, that browser
can't, and try and work out which browser is currently browsing the site.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

[James Pickering]

Re: XHTML Problems

The following message exchange (extracts) produced a disappointing
result for me:

A query to my Web Hosting Service.....

".......... The W3C has attempted to resolve this situation by
installing Content-Negotiation on their Server (to be a model for
others) that is supposed to offer a choice of content (MIME) type
text/html or application/xhtml+xml XHTML documents to browsers so that
they can render them according to their capabilities
(http://www.w3.org/2003/01/xhtml-mime...nt-negotiation)
........... I have tried some scripting routines of my own to effect
content negotiation on your server without success -- now I solicit
your help -- please .........."

Their response ..........

"I'm sorry but we do not have any directions or suggestions for setting
up such a thing on your account. As a note - we have serveral load
balanced webservers but the Zeus server version on some are different
than others which may make advanced hardly used features such as
content negotiation unreliable or unavailable. I hope I have answered
your question".

Now I have to retain a new Web Host Service (that utilizes Apache,
for instance) if I wish to implement content-negotiation. I wonder how
many other Web authors are facing the same situation?

James Pickering
Pickering Pages

http://www.jp29.org/

[Alan J. Flavell]

Re: XHTML Problems

On Wed, 6 Jul 2005, Tim wrote:
[color=blue]
> Andy Dingley <dingbat@codesm iths.com> posted:
>[color=green][color=darkred]
> >>> What I'm looking for is content negotiation that can silently
> >>> choose to deliver either XHTML, or Appendix C XHTML-as-HTML,
> >>> according to browser acceptance. Is this possible ? Would you
> >>> happen to have an example of it that we might learn from ?[/color][/color]
>
> Tim wrote:
>[color=green][color=darkred]
> >> Possible, but why bother. And I can't think of an example,
> >> because it's pointless.[/color][/color]
>
> "Alan J. Flavell" <flavell@physic s.gla.ac.uk> posted:
>[color=green]
> > As I say on my cited page, if you implement server-side negotation
> > then I would recommend also implementing some other way of getting
> > to the content. Server-side negotiation works fine in
> > properly-configured web-compatible browsers, but many users will
> > be using something that fails one or both of those criteria.
> >
> > http://ppewww.ph.gla.ac.uk/~flavell/www/lang-neg.html[/color]
>
> I mean, I couldn't see the point in serving the same XHTML page with
> one MIME type or another based on some presumption that one will do
> the job better than the other. I can't see the point in doing
> *that* both ways.[/color]

OK, I can't disagree with that specific point, but it doesn't negate
the general principle of server-side negotiation, which (under the
limitations that I already mentioned) really does work.

You'd have every right to discourage the questioner from wanting to
serve XHTML "properly" to browsers which can cope with it, and
compatibly as text/html to those that can't, if that's your intention,

I'm just trying to make sure you don't use this as a weapon to diss
the whole principle of server-side negotiation. *If* the questioner
has decided they want to do it despite your discouragement, then I
still say that server-side negotiation can be used. Some kind of
fallback is needed, e.g for situations where browsers send nothing
more informative than "*/*" in their accept header, they evidently
have to be sent text/html in the interests of compatibility. I'm
confident that this can be done (if necessary using a type-map file,
as I said), although I don't currently have a demonstration to offer
you. Mark Tranchant has a page about it, let's see:

http://tranchant.plus.com/notes/multiviews

Oh yes, this was specifically aimed at PHP, but the principles are
much the same I think.
[color=blue][color=green]
> > Of course MSIE doesn't implement anything that could be useful for
> > server-side negotiation (quite the opposite in fact), but it rules
> > itself out as a web-compatible browser in so many other ways too.
> > If you follow the advice to implement some alternative way of
> > accessing the content, this need not be a specific problem.[/color]
>
> Which is what I was getting at. If I were to try and either server
> XHTML as XHTML, or fake it as HTML, I can't rely on a browser saying
> it can handle it or not (because some just lie).[/color]

If they lie about that, then they will get what they asked for, I'm
afraid. On the other hand they do have every right to lie about their
user-agent, and many of them do so, so one would be MOST unwise to put
any reliance on that; but if they lie about their content-type
capability in their Accept header, then that's nobody's fault but
their own.

F.y.i, MSIE will typically say in its Accept header that it likes MS
Word files and Excel files (if you've got MS Office or similar
products installed), but does not Accept text/html , other than under
the provisions of "*/*. So if you have an MS Word version of your
document, server-side negotiation will NEVER offer the HTML version to
an MSIE user, it will always show your MS Word version as the only
suitable format, since the "*/" would only be resorted to if an
explicit match has not been found. I say again, you also need to
supply some other route to your resources, if only for such crippled
users to find the alternatives.
[color=blue]
> So, the usual stupid trick is for the webmaster (sneer) to decide
> that this browser can, that browser can't, and try and work out
> which browser is currently browsing the site.[/color]

So "don't do that".

all the best

[Nick Kew]

Re: XHTML Problems

James Pickering wrote:
[color=blue]
> Now I have to retain a new Web Host Service (that utilizes Apache,
> for instance) if I wish to implement content-negotiation. I wonder how
> many other Web authors are facing the same situation?[/color]

The reply wasn't clear to me: if you could point them to the relevant
documentation, would they set it up?

I don't know zeus, but I'd be surprised if it doesn't support
content negotiation.

--
Nick Kew

[James Pickering]

Re: XHTML Problems

Nick Kew wrote:[color=blue]
> James Pickering wrote:
>[color=green]
> > Now I have to retain a new Web Host Service (that utilizes Apache,
> > for instance) if I wish to implement content-negotiation. I wonder how
> > many other Web authors are facing the same situation?[/color]
>
> The reply wasn't clear to me: if you could point them to the relevant
> documentation, would they set it up?
>
> I don't know zeus, but I'd be surprised if it doesn't support
> content negotiation.
>
> --
> Nick Kew[/color]

Let me assure that I provided them with very comprehensive references,
Nick, including the article with which I led off this thread, links to
all of the W3C pages and documents -- and numerous private Web pages --
plus several phone conversations that I initiated with my Web Host
Technical staff relating to content negotiation. I only included
fragments of my message exchanges here.

There responses were very clear and unequivocating to me -- they
couldn't and wouldn't implement content-negotiation on their Zeus
implementation.

Here is my last interchange with them ..........

Thank you for your prompt reply. Unfortunately, I need
content-negotiation and so I will have to find a new Web Hosting
service.

Best regards,

James Pickering

"Hello,

I'm sorry to hear that. The cancellation form is at .........."

[James Pickering]

Re: XHTML Problems

I previously wrote:
[color=blue]
> .......... I have tried some scripting routines of my own to effect
> content negotiation on my Zeus server without success ........[/color]

Please check http://www.jp29.org/content-neg.php in your Browser(s) and
report if it renders as Content-Type: application/xhtml+xml with
correct functionality in your XML compliant Browsers (Firefox, et al)
and Content-Type: text/html in your MSIE and legacy Browsers.

James Pickering