[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xml-dev] So maybe ID isn't a problem after all.
- To: Mark Baker <firstname.lastname@example.org>
- Subject: Re: [xml-dev] So maybe ID isn't a problem after all.
- From: Gavin Thomas Nicol <email@example.com>
- Date: Tue, 13 Nov 2001 13:10:21 -0500
- Cc: firstname.lastname@example.org
- In-reply-to: <200111131523.KAA04348@markbaker.ca>
- Organization: Red Bridge Interactive, Inc.
- References: <200111131523.KAA04348@markbaker.ca>
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
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
It's funny that I can see similarities in HTTP development and XML