>
> On 5/10/06, Thomas Broyer <[EMAIL PROTECTED]> wrote:
> > Could you enlighten me about other potential problems with conneg? (it
> > seems I'm not the only one here needing more details)
>
> I've written about some of the problems here:
>
> http://bitworking.org/news/WebServicesAndContentNegotiation
The
first thing that could go wrong is a bug or mis-configuration on the
client or the server. This has happened to me in the past. The W3C does
conneg on some of their recommendations, returning either HTML or plain
text based on the clients capabilities. This is fine, but one day their
server was either confused or mis-configured because it would only
serve the recommendation in plain/text. I really needed
the HTML form, but after trying multiple browsers from multipe
locations I could only retrieve the text format. I ended up pulling the
HTML version out of the Google cache.
The
second problem that I ran across highlights the real core problem with
conneg. I was trying to use the W3C XSLT service to do some
transformations on my web pages. Now the server side software I use to
run Well-Formed Web does conneg and can return either HTML or an RSS
item fragment for each URI. At the time I was serving up XHTML 1.0,
which is valid XML and thus good input into an XSLT service. So the way
the XSLT service works is that you enter two URIs, one for the source
content and the other for the XSLT sheet to apply to the source
content. My transformation kept failing and it was because of the
Accept headers that the XSLT service sent when it went to retrieve the
source content. My server kept returning the RSS item fragment and not
the XHTML. Now this would have been fine if I wanted to apply an XSLT
sheet to my RSS item fragment, but in this case I wanted it to apply to
the XHTML. Note that the problem could have been completely reversed, I
could have been trying to apply the XSLT to the RSS item and not to the
XHTML and my server could have returned the XHTML all the time. The
crux of the problem is that when I gave the URI to the XSLT
transformation service I have no way of specifying what mime-type to
request. I get no chance to tweak the services Accept:
header.
I think this is certainly
an argument for providing separate URIs to serve up different
representations. This is actually a fairly standard thing in web
services -- "type=html", "type=rss", or "type=atom" are pretty common
query parameters on web service URIs. Does this imply that a service cannot also do content negotiation if no preference is specified in the URI (if a "base URI" alone is used)? I don't know.
There is a separate question lurking here: Whether or not we mandate multiple URIs, or allow them, or ban content negotiation... is there one resource hiding behind the URI(s) or two?
John
