Jan Algermissen wrote:
>
> On Mar 24, 2006, at 1:07 PM, Jon Hanna wrote:
>
> >
> > Why not. It tells us that the request cannot be successfully tried
> > againt without alteration. It tells proxies that too.
> >
>
> <quote>
> 10.4.1 400 Bad Request
>
> The request could not be understood by the server due to malformed
> syntax. The client SHOULD NOT repeat the request without modifications.
> </quote>
418 Invalid
The request could not be completed due to a validation failing against
the sent entity. This code is only allowed in situations where it is
expected that the user might be able to resubmit the request with valid
content and where the sent content was syntactically correct according
to its media type. The response body SHOULD include enough information
for the user to recognize the source of the conflict. Invalidations are
most likely to occur in response to a PUT or POST request.
... Actually, I have wondered about an approach like: Accept: text/xmlns+xml;uri=http://xmlns1;uri=http://xmlns2 This would, in effect, say "send me any...
... 418 Invalid The request could not be completed due to a validation failing against the sent entity. This code is only allowed in situations where it is ...
... Thanks, yes. But in which HTTTP specs is that in? Jan ... ________________________________________________________________________ _______________ Jan...
... The next one? An extension RFC? The point is this: when a specified item has "kinda like" semantics is *exactly* when a new item should be defined....
... I'd say that is how the deployed web *is* rather then how it *works*. Imagine if invalid form postings returned 4xx error codes when appropriate, it would...
... I always tell my teams and the people I'm mentoring that they should return a correct error code (or 400 or 500) with standard web interactions. It doesn't...
... Yep, that's what I would do, though a properly specified response code would never include that second sentence "This code is only allowed ..." since...
... I can think of no reason. Just so I understand, since WebDAV is a HTTP extension, you can (re)use these codes outside a WebDav context, right? cheers Bill...
... Could someone help me understand the relationship between standard error codes and extensions please? If I got 422, how would I know how to interpret it? ...
Ideally there'd be an HTTP response code registry. Since there isn't one (AFAIK), just Google for it. http://www.google.com/search?q=http+422+response Mark....
http://www.ietf.org/rfc/rfc4028.txt seems the best, but a little unmatched to the definition earlier in this thread? Thanks Mark. ... -- Dave Pawson XSLT...
... Either: a. You'd know what a 422 meant from the WebDav spec or elsewhere, and treat it according to that. b. You treat it as an unknown error in the range...
Having problems with message search?
Fill out this form to ensure your group is one of the first to be migrated to the new message search system.
Offline 
Send Email
