- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 4 Jul 2012 05:26:47 +1000
- To: John Sullivan <jsullivan@velocix.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 03/07/2012, at 11:58 PM, John Sullivan wrote: > Mark Nottingham wrote: >> Note that the new consideration -- identifying who can generate the status code -- implies (as Julian pointed out) that we should eat our own dogfood and define it for ours. >> >> Looking through p2, this was actually easier than I thought it might be; most of the status codes already are pretty specific (using phrases like "the resource indicates...", which can logically be read to make it specific to origins). The only issues of interpretation I found are marked by "!" below. >> >> O - Origin server (including gateways) >> I - Intermediaries (proxy or gateway) >> P - Proxies (not gateways) >> S - All servers >> >> Successful 2xx >> O 200 OK > > Does an intermediate selected through use of Max-Forwards count > as an origin for this purpose when fielding TRACE or OPTIONS? Good point. This will have to be special-cased in the text. >> Client Error 4xx >> O! 403 Forbidden > > Definitely S - see the previous discussion around 451 where it was > widely accepted that 403 was a legitimate response from an intermediate > that was unwilling for undisclosed reasons to proxy at all for a given > URI/client. Personally, I agree. I think we can work around any potential issues here by making this just prose; i.e., "ought to" instead of MUST. >> Server Error 5xx >> S 500 Internal Server Error >> O! 501 Not Implemented > > Again, if an intermediate is refusing to handle TRACE/OPTIONS > targeted at it, this would seem the appropriate response. Ack; same as above. Thanks, -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 3 July 2012 19:27:15 UTC