Hi Melanie, in your original mail you listed the Request and Response header. For me it seamed that those headers where from the OPTIONS request and not from the actual DELETE. This was the reason why I ask if you are sure that the Browser actually sends the DELETE request.
I am assuming the the DELETE is not sent because some kind of problem. Its just a guess, but maybe because jQuery wants to use the "X-Requested-With" header and it is not included in the "Access-Control-Allow-Headers". As the Stanbol CORS implementation currently only echoes the parsed "Access-Control-Request-Headers" values you could try to add additional headers to that list. I am not an expert in Javascript development and Web-Browser debugging, but I will try to get some help from szaby. Maybe he can help me in reproducing this. best Rupert On Wed, May 30, 2012 at 2:29 PM, Melanie Reiplinger <[email protected]> wrote: > Hi Rupert, > > Since I can inspect the complete request and response headers in the > Developer Tools Window of the Browser, I supposed that the PUT or DELETE > requests are actually sent (since if a request fails in sending, I can only > see fragments of the headers). > > The returned "Access-Control-Allow-Headers" holds origin, content-type, > accept > The requested looks just the same: > Access-Control-Request-Headers: > origin, content-type, accept > > > > Am 25.05.2012 12:52, schrieb Rupert Westenthaler: > >> Hi Melanie, >> >> does the Server actually send the PUT, DELETE request, or does it >> already fail after receiving the OPTIONS request? >> >> What would be the HTTP headers for the PUT, DELETE request. Maybe they >> do not match with the returned "Access-Control-Allow-Headers" (origin, >> content-type, accept). >> >> best >> Rupert >> >> On Thu, May 24, 2012 at 6:19 PM, Melanie Reiplinger >> <[email protected]> wrote: >>> >>> Hi all. >>> >>> Has someone successfully done PUT or DELETE requests on e.g. the >>> entityhub >>> via XMLHttpRequest? >>> I'm at revision 1341602 and from looking at the CorsHelper code I figured >>> that the Access-Control-Allow-Methods should now be set in the response >>> header, but I'm still getting >>> >>> XMLHttpRequest cannot load<url> >>> >>> <http://lnv-89012.dfki.uni-sb.de:9000/entityhub/entity?id=http%3A//developer.yahoo.com/javascript/howto-proxy.html>. >>> Method DELETE is not allowed by Access-Control-Allow-Methods. >>> >>> Do I have to send something special in my Request header to make it >>> work?: >>> >>> 1. >>> Request URL: >>> >>> >>> http://lnv-89012.dfki.uni-sb.de:9000/entityhub/entity?id=http%3A//developer.yahoo.com/javascript/howto-proxy.html >>> 2. >>> Request Method: >>> OPTIONS >>> 3. >>> Status Code: 200 OK >>> >>> Request Header: >>> >>> 1. >>> Accept: >>> */* >>> 2. >>> Accept-Charset: >>> ISO-8859-1,utf-8;q=0.7,*;q=0.3 >>> 3. >>> Accept-Encoding: >>> gzip,deflate,sdch >>> 4. >>> Accept-Language: >>> de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4 >>> 5. >>> Access-Control-Request-Headers: >>> origin, content-type, accept >>> 6. >>> Access-Control-Request-Method: >>> DELETE >>> 7. >>> Connection: >>> keep-alive >>> 8. >>> Host: >>> lnv-89012.dfki.uni-sb.de:9000 >>> 9. >>> Origin: >>> http://localhost >>> 10. >>> Referer: >>> >>> >>> http://localhost/VIE/test/?filter=vie.js%20-%20Apache%20Stanbol%20Service%3A%20VIE.js%20StanbolService%20-%20CRUD%20on%20local%20entities >>> 11. >>> User-Agent: >>> Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, >>> like Gecko) Chrome/19.0.1084.52 Safari/536.5 >>> 1. Query String Parametersview URL encoded >>> 1. >>> id: >>> http://developer.yahoo.com/javascript/howto-proxy.html >>> >>> >>> Response Header: >>> >>> 1. >>> Access-Control-Allow-Headers: >>> origin, content-type, accept >>> 2. >>> Access-Control-Allow-Origin: >>> * >>> 3. >>> Access-Control-Request-Method: >>> GET, POST, PUT, DELETE, OPTIONS >>> 4. >>> Content-Length: >>> 0 >>> 5. >>> Server: >>> Jetty(6.1.x) >>> >>> >> >> > -- | Rupert Westenthaler [email protected] | Bodenlehenstraße 11 ++43-699-11108907 | A-5500 Bischofshofen
