Hi Melanie
On Wed, Jun 27, 2012 at 3:04 PM, Melanie Reiplinger
<[email protected]> wrote:
> Hi Rupert.
>
> The Access-Control-Allow-Methods is now sent in the response. And again, I
> get
> Method PUT is not allowed by Access-Control-Allow-Methods.
> Headers of preflight request are attached below. Looks to me like here, the
> PUT and DELETE are really simply not allowed on serverside (only GET; POST;
> OPTIONS). For the entityhub enpoint, my PUT and DELETE requests both work on
> the updated version :-)
Does PUT now work or not? Do you indicate that PUT and DELETE now work
on the Entityhub, but you do have still problems on other RESTful
endpoints?
If so, than we are at least one step further - as we have now
conformation that CORES works.
Implementors of RESTful services need to parse the HTTP methods they
want to provide. So if you get "not allowed" errors it is a bug in the
implementation.
I think the best would be to just report in the form
{uri} {method}
e.g.
http://lnv-89012.dfki.uni-sb.de:9001/ontonet/ontology/pizzaScope PUT
this should it make easy to fix those on the server side.
I think it is best to use STANBOL-105 for reporting
best
Rupert
>
> 1.
> Request URL:
> http://lnv-89012.dfki.uni-sb.de:9001/ontonet/ontology/pizzaScope
>
> 2.
> Request Method:
> OPTIONS
> 3.
> Status Code:
> 200 OK
> 4. Request Headersview source
> 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, accept
> 6.
> Access-Control-Request-Method:
> PUT
> 7.
> Cache-Control:
> max-age=0
> 8.
> Connection:
> keep-alive
> 9.
> Host:
> lnv-89012.dfki.uni-sb.de:9001
> 10.
> Origin:
> http://localhost
> 11.
> Referer:
> http://localhost/VIE_testing/ontonet.html
> 12.
>
> User-Agent:
> Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML,
> like Gecko) Chrome/19.0.1084.56 Safari/536.5
> 5. Response Headersview source
> 1.
> Access-Control-Allow-Headers:
> origin, accept
> 2.
> Access-Control-Allow-Methods:
> GET, POST, OPTIONS
> 3.
> Access-Control-Allow-Origin:
> *
> 4.
> Access-Control-Expose-Headers:
> Location
> 5.
> Content-Length:
> 0
> 6.
> Server:
> Jetty(6.1.x)
>
>
>
>
> Am 25.06.2012 23:02, schrieb Rupert Westenthaler:
>
>> On 25.06.2012, at 21:21, Melanie Reiplinger wrote:
>>
>>> Hi Rupert,
>>>
>>> I tried with the your suggestion, but sending the "X-Requested-With"
>>> header is echoed in the "Access-Control-Allow-Headers", but does not help in
>>> the PUT / DELETE problem. For some reason, the preflight request fails.
>>> Also, there is no "Access-Control-Allow-Methods" send back in reply,
>>> instead the "Access-Control-Request-Method.
>>>
>> What Stanbol version do you test against. In the trunk there is now a unit
>> test that validates that the "Access-Control-Allow-Methods" is correctly
>> added to CORS preflight responses [1]. So if you still get the
>> "Access-Control-Request-Method" it would explain why you do not get the
>> expected results.
>>
>> Please make sure that you use "org.apache.stanbol.commons.web.base"
>> version "0.10.1-incubating-SNAPSHOT". You can check that in the bundles tab
>> of the Apache Felix Webconsole
>>
>> best
>> Rupert
>>
>>
>> [1]
>> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/web/base/src/test/java/org/apache/stanbol/commons/web/base/CorsAccessControlAllowMethodTest.java
>>
>>
>>> 1.
>>> Request URL:
>>>
>>> http://dev.iks-project.eu:8081/entityhub/entity?id=http://developer.yahoo.com/javascript/howto-proxy.html
>>> 2.
>>> Request Method:
>>> OPTIONS
>>> 3.
>>> Status Code:
>>> 200 OK
>>> 4. Request Headersview source
>>> 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, x-requested-with, accept
>>> 6.
>>> Access-Control-Request-Method:
>>> DELETE
>>> 7.
>>> Connection:
>>> keep-alive
>>> 8.
>>> Host:
>>> dev.iks-project.eu:8081
>>> 9.
>>> Origin:
>>> http://localhost
>>> 10.
>>> Referer:
>>> http://localhost/VIE_testing/UD.html
>>> 11.
>>> User-Agent:
>>> Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML,
>>> like Gecko) Chrome/19.0.1084.56 Safari/536.5
>>> 5. Query String Parametersview URL encoded
>>> 1.
>>> id:
>>> http://developer.yahoo.com/javascript/howto-proxy.html
>>> 6. Response Headersview source
>>> 1.
>>> Access-Control-Allow-Headers:
>>> origin, x-requested-with, 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)
>>>
>>>
>>>
>>> Am 30.05.2012 15:14, schrieb Rupert Westenthaler:
>>>>
>>>> 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
