search

medabdellahi / google-caldav-issues

Automatically exported from code.google.com/p/google-caldav-issues
0 stars 0 forks source link

wrong status code on PUT ical resource #16

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. caldav PUT /path/to/resource/UID.ics

What is the expected output? What do you see instead?
EXPECTED: 201 Created
RETURNED: 204 No Content

What version of the product are you using? On what operating system?

Please provide any additional information below.
All other caldav server return 201 on PUT as in examples provided in Caldav RFC

Original issue reported on code.google.com by robipo...@gmail.com on 8 Aug 2008 at 9:58

GoogleCodeExporter commented 9 years ago 
201 should be returned on inital PUT and 204 when overriding existing resource.

Original comment by filip.na...@gmail.com on 8 Aug 2008 at 10:57

GoogleCodeExporter commented 9 years ago 
The test is about inital put, not an override.
Test is made with junit and consists of:

1) PUT event
2) re-PUT event using if-tag (returns CONFLICT)
3) DELETE event

Original comment by robipo...@gmail.com on 8 Aug 2008 at 12:42

GoogleCodeExporter commented 9 years ago 
Just for completeness, 9.6 PUT:
  http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

"If a new resource is created, the origin server MUST inform the user agent via 
the
201 (Created) response."

Obviously a client should be tolerant and process any 2xx response as valid. A 
client
gains nothing in the 201 response status if it properly uses the If-None-Match: 
*
header. (the If-None-Match already guarantees that the resource will be fresh)

Original comment by helge.h...@googlemail.com on 11 Aug 2008 at 8:52

GoogleCodeExporter commented 9 years ago 
thx helge.

proper responses should be:
- PUT /new/resource.ics (without if-tag): CREATED
- re-PUT with if-none-match: PRECONDITION FAILED

imho client api should let the developer choiche the behavior of his apps, so 
the
junits should not be too tolerant if server is not polite ;)
Peace, R.

Original comment by robipo...@gmail.com on 14 Aug 2008 at 9:23

GoogleCodeExporter commented 9 years ago 
This is fixed. Now you get 201/204 properly. You also get "412 Precondition 
Failed"
in case of etag conflict.

Original comment by di...@google.com on 2 Oct 2008 at 11:58