- From: Wingard, Steve <swingard@spyglass.com>
- Date: Tue, 17 Nov 1998 12:23:56 -0600
- To: "'koen@win.tue.nl'" <koen@win.tue.nl>
- Cc: jg@pa.dec.com, http-wg@hplb.hpl.hp.com, "Adams, Glenn" <gadams@spyglass.com>
Koen Holtman: > Wingard, Steve: > > > >ADAMS84b (406 / Accept-Charset): > > > >To me, the main issue is that the language in 14.2 implies an > >"either/or" choice when it means to suggest optional additional > >behavior. > > > >The description of the 406 status code (sec. 10.4.7) already says the > >response SHOULD also contain an explanatory entity (unless > the response > >is to a HEAD request), *and* that the entity does not have to be > >"acceptable" to the user agent (according to the > constellation of Accept > >header fields the user agent has sent). > > > >So I interpret the the clause: > > > > "...the server SHOULD send an error response with the 406 (not > >acceptable) status code, though the sending of an > unacceptable response > >is also allowed." > > > >to mean > > > > "... the server SHOULD send an error response with the 406 (not > >acceptable) status code, though the character set of the > response entity > >may not be acceptable to the user agent based upon the Accept-Charset > >information it provided." > > No, that is probably not the intended meaning. I can't recall whether > I wrote that particular sentence but I definately wrote sentences like > it elsewhere. > > The above probably refers to the usual problem of what to send as a > response for un-negotiated resources only available in a single form. > Sending an response with a known-unacceptable entity is not that good, > but sending an error response is hardly better, so in this case the > spec intends to allow the server author to freely choose between the > two evils. > > No edit is required in my opinion. Ah. Now I understand. Maybe I was just being dense in interpreting it to mean the entity sent with the 406, but perhaps section 10.4.7 could capture your explanation above a little more explicitly to help clarify it. > >I think the SHOULD needs to stay a SHOULD, but the second > part might be > >redundant given the existing language in 10.4.7. > > True, one could see it as a restatement the language in 10.4.7. Given that the other references (Accept, sec. 14.1; Accept-Encoding, sec. 14.3) do not include that same language, is it better to eliminate it from 14.2, OR are there more of these "special cases" (where it may be preferable for the server to go ahead and return something "unacceptable") for Accept-Charset that led to have the alternative explicitly spelled out here?
Received on Tuesday, 17 November 1998 11:33:21 UTC