[caldeveloper-l] XML bodies to HTTP error responses

[Michael Douglass]

For some reason ended up being marked as spam by google...

rfc2616 says:

The request could not be completed due to a conflict with the current 
state of the resource. This code is only allowed in situations where it 
is expected that the user might be able to resolve the conflict and 
resubmit the request. The response body SHOULD include enough 
information for the user to recognize the source of the conflict. 
Ideally, the response entity would include enough information for the 
user or user agent to fix the problem; however, that might not be 
possible and is not required.

The point of the body is to help the user. If it's stripped out and 
replaced by a generic "don't work" that's not very helpful.

And this goes to great lengths to explain what should be in an error 
response.

https://nordicapis.com/best-practices-api-error-handling/

Apparently facebook hands back a lot of info...

On 1/15/19 11:16, David Given wrote:
> Hello everyone,
>
> We've encountered a situation where a proxy is stripping the bodies 
> from HTTP CalDAV error responses, under the impression that the HTTP 
> error response code is the only bit that clients are interested in --- 
> instead it's replacing the body with boilerplate text.
>
> This appears to result in a violation of the SHALL mandate in 
> paragraph 1.3 of the CalDAV spec, and there's an example in paragraph 
> 7.8.10. However, in real life I've seen servers which return 
> boilerplate XML in that situation with no useful information in it, 
> and apparently they're getting away with this.
>
> Can anyone point me at any concrete situations where this behaviour 
> will cause problems (which I can use to persuade the proxy to change 
> its behaviour)? Alternatively, can we simply decide that this is 
> non-compliant but harmless and forget about it?
>
> Thanks!
>
> David Given
> dtrg at google.com <mailto:dtrg at google.com>
>
>
> _______________________________________________
> caldeveloper-l mailing list
> caldeveloper-l at lists.calconnect.org
> http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.calconnect.org/pipermail/caldeveloper-l-calconnect.org/attachments/20190213/10cae93b/attachment.html>