Re: [CORS] HTTP error codes in preflight response

On Thu, Sep 23, 2010 at 2:17 AM, Julian Reschke wrote: > Also, somewhere else it was pointed out that OPTIONS differs from PROPFIND > in that PROPFIND can have a body. So can OPTIONS (see, for instance, > ). I was saying that the OPTI

Re: [CORS] HTTP error codes in preflight response

On 22.09.2010 21:42, Jonas Sicking wrote: ... It's not a problem if servers use OPTIONS for things other than CORS and that those things require authentication. At some point you have to inspect the OPTIONS request anyway to determine if it's an OPTIONS request made for CORS, or one made for the

Re: [CORS] HTTP error codes in preflight response

On Tue, 21 Sep 2010 11:04:33 +0200, Anne van Kesteren wrote: So preflight requests should only succeed if the status code of the response is 200, correct? All other status codes mean failure? (Not counting 1xx here, as they are transport codes, not response codes.) I now put this in the sp

Re: PROPFIND vs "simple methods", was: [CORS] HTTP error codes in preflight response

On Wed, 22 Sep 2010 17:59:35 +0200, Julian Reschke wrote: CORS, 6.1.5.: "To protect resources against cross-origin access with methods that have side effects an preflight request is made to ensure that the resource is ok with the request." I clarified this text. -- Anne van Kesteren ht

Re: [CORS] HTTP error codes in preflight response

On Wed, 22 Sep 2010 21:49:39 +0200, Julian Reschke wrote: Yes, as long as you do that. I don't think you can rely on that. Then for now not such a service would not be able to use CORS unless they change the way they handle OPTIONS. I think that is acceptable given that supporting authent

Re: PROPFIND vs "simple methods", was: [CORS] HTTP error codes in preflight response

On Wed, Sep 22, 2010 at 12:26 PM, Anne van Kesteren wrote: > On Wed, 22 Sep 2010 21:20:09 +0200, Jonas Sicking wrote: >> >> On Wed, Sep 22, 2010 at 12:16 PM, Anne van Kesteren >> wrote: >>> >>> We don't want to keep updating the "safe" list. So they're all "unsafe". >>> Or >>> maybe not "unsafe"

Re: PROPFIND vs "simple methods", was: [CORS] HTTP error codes in preflight response

On 22.09.2010 21:26, Anne van Kesteren wrote: On Wed, 22 Sep 2010 21:20:09 +0200, Jonas Sicking wrote: On Wed, Sep 22, 2010 at 12:16 PM, Anne van Kesteren wrote: We don't want to keep updating the "safe" list. So they're all "unsafe". Or maybe not "unsafe", just not compatible with HTML forms

Re: PROPFIND vs "simple methods", was: [CORS] HTTP error codes in preflight response

On Wed, Sep 22, 2010 at 12:16 PM, Anne van Kesteren wrote: > On Wed, 22 Sep 2010 20:19:08 +0200, Julian Reschke > wrote: >> >> For PROPFIND (and other methods defined to be "safe"): it really doesn't >> make sense to do a preflight OPTIONS for PROPFIND. Both are defined to be >> safe. Both could

Re: [CORS] HTTP error codes in preflight response

On 22.09.2010 21:42, Jonas Sicking wrote: ... So in these scenarios servers are set up to do authentication verification before handing the request to CGI-like code (i.e. things like php, asp, jsp, etc)? Can you point to any server software which have such a setup? ... As far as I recollect, th

Re: [CORS] HTTP error codes in preflight response

On Wed, Sep 22, 2010 at 12:34 PM, Julian Reschke wrote: > On 22.09.2010 20:22, Jonas Sicking wrote: >> >> ... >> First of all I assume that you're only talking about including >> credentials if the 'credentials' flag is set, right? >> ... > > Probably. I'm not totally familiar with the spec, I jus

Re: [CORS] HTTP error codes in preflight response

On 22.09.2010 20:22, Jonas Sicking wrote: ... First of all I assume that you're only talking about including credentials if the 'credentials' flag is set, right? ... Probably. I'm not totally familiar with the spec, I just observe its impact on certain scenarios :-). This would require some

Re: PROPFIND vs "simple methods", was: [CORS] HTTP error codes in preflight response

On 22.09.2010 21:16, Anne van Kesteren wrote: On Wed, 22 Sep 2010 20:19:08 +0200, Julian Reschke wrote: For PROPFIND (and other methods defined to be "safe"): it really doesn't make sense to do a preflight OPTIONS for PROPFIND. Both are defined to be safe. Both could have broken server implemen

Re: PROPFIND vs "simple methods", was: [CORS] HTTP error codes in preflight response

On Wed, 22 Sep 2010 21:20:09 +0200, Jonas Sicking wrote: On Wed, Sep 22, 2010 at 12:16 PM, Anne van Kesteren wrote: We don't want to keep updating the "safe" list. So they're all "unsafe". Or maybe not "unsafe", just not compatible with HTML forms. What we're really concerned about here i

Re: PROPFIND vs "simple methods", was: [CORS] HTTP error codes in preflight response

On 22.09.2010 20:25, Jonas Sicking wrote: ... For PROPFIND (and other methods defined to be "safe"): it really doesn't make sense to do a preflight OPTIONS for PROPFIND. Both are defined to be safe. Both could have broken server implementations. Note that the OPTIONS request always has an empt

Re: PROPFIND vs "simple methods", was: [CORS] HTTP error codes in preflight response

On Wed, 22 Sep 2010 20:19:08 +0200, Julian Reschke wrote: For PROPFIND (and other methods defined to be "safe"): it really doesn't make sense to do a preflight OPTIONS for PROPFIND. Both are defined to be safe. Both could have broken server implementations. We don't want to keep updating t

Re: PROPFIND vs "simple methods", was: [CORS] HTTP error codes in preflight response

On Wed, Sep 22, 2010 at 11:19 AM, Julian Reschke wrote: > On 22.09.2010 20:05, Jonas Sicking wrote: >> >> ... >> For what it's worth, I think "simple" is meant as "Must be handled by >> servers today as HTML implementations can already send this request >> cross site". Not as the HTTP definition o

Re: PROPFIND vs "simple methods", was: [CORS] HTTP error codes in preflight response

On 22.09.2010 20:05, Jonas Sicking wrote: ... For what it's worth, I think "simple" is meant as "Must be handled by servers today as HTML implementations can already send this request cross site". Not as the HTTP definition of "must/should not have side effects". ... Yes. That's why I think it

Re: [CORS] HTTP error codes in preflight response

On Wed, Sep 22, 2010 at 7:15 AM, Julian Reschke wrote: > On 21.09.2010 02:05, Jonas Sicking wrote: >> >> Hi All, >> >> CORS was recently clarified to say that error responses, such as >> 4xx/5xx responses, should not abort the various algorithms but instead >> such a response should be forwarded t

Re: PROPFIND vs "simple methods", was: [CORS] HTTP error codes in preflight response

On Wed, Sep 22, 2010 at 8:59 AM, Julian Reschke wrote: > On 22.09.2010 16:15, Julian Reschke wrote: >> >> On 21.09.2010 02:05, Jonas Sicking wrote: >>> >>> Hi All, >>> >>> CORS was recently clarified to say that error responses, such as >>> 4xx/5xx responses, should not abort the various algorithm

PROPFIND vs "simple methods", was: [CORS] HTTP error codes in preflight response

On 22.09.2010 16:15, Julian Reschke wrote: On 21.09.2010 02:05, Jonas Sicking wrote: Hi All, CORS was recently clarified to say that error responses, such as 4xx/5xx responses, should not abort the various algorithms but instead such a response should be forwarded to, for example, the XMLHttpRe

Re: [CORS] HTTP error codes in preflight response

On 21.09.2010 02:05, Jonas Sicking wrote: Hi All, CORS was recently clarified to say that error responses, such as 4xx/5xx responses, should not abort the various algorithms but instead such a response should be forwarded to, for example, the XMLHttpRequest implementation. However it seems some

Re: [CORS] HTTP error codes in preflight response

On Tue, 21 Sep 2010 12:04:44 +0200, Julian Reschke wrote: To address use case we currently don't know of. Remember, "extensibility". We can easily allow more status codes when the use cases exists. That would also be better in case client updates are required. -- Anne van Kesteren http:

Re: [CORS] HTTP error codes in preflight response

On 21.09.2010 11:58, Anne van Kesteren wrote: On Tue, 21 Sep 2010 11:53:39 +0200, Julian Reschke wrote: How do you know now that 234 will not make sense in two years from now? Common sense. But apart from that it seems saner to just operate from a whitelist here. We only need one response cod

Re: [CORS] HTTP error codes in preflight response

On Tue, 21 Sep 2010 11:53:39 +0200, Julian Reschke wrote: How do you know now that 234 will not make sense in two years from now? Common sense. But apart from that it seems saner to just operate from a whitelist here. We only need one response code for the protocol to work -- 200 -- why m

Re: [CORS] HTTP error codes in preflight response

On 21.09.2010 11:48, Anne van Kesteren wrote: On Tue, 21 Sep 2010 11:44:46 +0200, Julian Reschke wrote: All 2xx codes are success codes. Sure, but the others make no sense in this context and simply checking for 200 is easier than checking for a range. How do you know now that 234 will not

Re: [CORS] HTTP error codes in preflight response

On Tue, 21 Sep 2010 11:44:46 +0200, Julian Reschke wrote: All 2xx codes are success codes. Sure, but the others make no sense in this context and simply checking for 200 is easier than checking for a range. -- Anne van Kesteren http://annevankesteren.nl/

Re: [CORS] HTTP error codes in preflight response

On 21.09.2010 11:04, Anne van Kesteren wrote: On Tue, 21 Sep 2010 02:05:10 +0200, Jonas Sicking wrote: CORS was recently clarified to say that error responses, such as 4xx/5xx responses, should not abort the various algorithms but instead such a response should be forwarded to, for example, the

Re: [CORS] HTTP error codes in preflight response

Anne van Kesteren wrote: On Tue, 21 Sep 2010 02:05:10 +0200, Jonas Sicking wrote: CORS was recently clarified to say that error responses, such as 4xx/5xx responses, should not abort the various algorithms but instead such a response should be forwarded to, for example, the XMLHttpRequest imple

Re: [CORS] HTTP error codes in preflight response

On Tue, 21 Sep 2010 02:05:10 +0200, Jonas Sicking wrote: CORS was recently clarified to say that error responses, such as 4xx/5xx responses, should not abort the various algorithms but instead such a response should be forwarded to, for example, the XMLHttpRequest implementation. However it see

[CORS] HTTP error codes in preflight response

Hi All, CORS was recently clarified to say that error responses, such as 4xx/5xx responses, should not abort the various algorithms but instead such a response should be forwarded to, for example, the XMLHttpRequest implementation. However it seems somewhat strange to me to do this with responses