• To: Mark Baker <distobj@a...>
• Subject: Re: So maybe ID isn't a problem after all.
• From: Gavin Thomas Nicol <gtn@r...>
• Date: Tue, 13 Nov 2001 13:10:21 -0500
• Cc: xml-dev@l...
• In-reply-to: <200111131523.KAA04348@m...>
• Organization: Red Bridge Interactive, Inc.
• References: <200111131523.KAA04348@m...>

On Tuesday 13 November 2001 10:23 am, Mark Baker wrote:
> > That doesn't diminish the point that the server is obligated to send back
> > something with approximately the same semantics. If it doesn't, all bets
> > are off...
>
> Not at all.  The server SHOULD do one of two things; either match the
> specification of the desired content type in the Accept request header,
> or barf with a 406 (Not Acceptable) error.

That's my point though. Sending back a PDF when I wanted XML isn't doing me 
any favors, and if a server cannot fullfil my request, it should send back an 
error.

Personally, I think HTTP content negotiation is misguided anyway... that 
functionality (or at least, the more advanced possibilities of it) deserve to 
be one layer up in the application logic, not the protocol. That's why all 
the more modern serving architectures (cocoon, et al) take over the 
functionality.

It's funny that I can see similarities in HTTP development and XML 
development...

• Prev by Date: Re: So maybe ID isn't a problem after all.
• Next by Date: [Announce] XML:DB XML Database API Reference Implementation
• Previous by thread: Re: So maybe ID isn't a problem after all.
• Next by thread: Kent's "Data and Reality"
• Index(es):
  • Date
  • Thread