Re: HTML Validator HTTP Accept

Sierk Bornemann wrote:
> 
>> I'm a big fan of URI based overrides of content-negotiation 

> Much content in real web life is generated content. Generated
> by content management software, blog software. Do you want to provide
> each and every single web document twice -- one document as XHTML
> document with XHTML doctype and served as application/xhtml+xml and the
> other identical document as HTML document with a HTML doctype and served
> with text/html?

If the content is generated, then whatever is generating it can be set
to generate differently marked up content depending on the URI.
Converting XHTML to HTML is relatively trivial with XSLT or libtidy.

... but frankly - XHTML provides little advantage in most cases. So
unless there was a real benefit to it, I'd just generate HTML from the
outset and not worry about content negotiation.

<snip>

> So, what to do? What's the ideal webserver configuration (Apache) to solve 
> this situation, while NOT relying on Accept headers and not using
dynamically
> written stuff via PHP or JSP?

Umm. Err. Why are you imposing such ridiculous constraints?

If you want to do content negotiation then:

(a) You have to use the Accept header, since the next best alternative
(the user-agent header) is an insane approach. (The trick is that you
have to do it right and pay attention to q values ...

  "What would sir like for dinner?"

  "Anything, so long as it doesn't have peanuts."

  [ 20 minutes later ]

  "I'm dying!"

  "Well, you said 'peanuts', so I got you something with peanuts".

)

and

(b) You have to have something to make the decision. Apache built in,
some scripting language, whatever.

If you can't use one of those then your choices are:

(1) Don't do anything as complicated as content negotiation

or

(2) Get a better server!

-- 
David Dorward                               <http://dorward.me.uk/>

Received on Thursday, 11 December 2008 20:50:17 UTC