You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@stanbol.apache.org by Melanie Reiplinger <me...@dfki.de> on 2012/05/24 18:19:37 UTC

Allow-Methods header

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)

Re: Allow-Methods header

Posted by Melanie Reiplinger <me...@dfki.de>.

Hi Alessandro.

I'm not sure I understand what you mean (sorry if I'm being redundant 
here, but I'll simply summarize what I understood). I'm new to CORS and 
to HttpRequests in general, but from what I read so far I got that every 
preflight request is using method OPTIONS.  E.g. in [1], it says that

"if the resource author wants to be able to handle cross-origin requests 
using methods other thansimple methods 
<http://www.w3.org/TR/cors/#simple-method>. In that case the author 
needs to reply to a preflight request that uses the|OPTIONS|method and 
then needs to handle the actual request that uses the desired method 
(|DELETE|or PUT) and give an appropriate response. The response to the 
preflight request could have the following headers specified:

|Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: PUT, DELETE|(, otherMethods)* 	"

My preflight request has verb OPTIONS and sends 
'Access-Control-Request-Method: (PUT|DELETE)' in order to check whether 
PUT|DELETE are allowed methods for that endpoint. For this request, I 
get status code 200 OK, but the PUT request is not executed since the 
returned response contains only 'Access-Control-Allow-Methods: GET, 
POST, OPTIONS'.

On the entityhub/entity/, on the other hand, it's also a preflight 
request (OPTIONS) asking for PUT, and the response returns 
'Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS'. And 
here, the PUT access works.

Best,
melanie

[1] http://www.w3.org/TR/cors/

Am 03.07.2012 18:01, schrieb Alessandro Adamou:
> On 7/2/12 8:35 PM, Melanie Reiplinger wrote:
>>>> presently NOT-working:
>>>> --------------------------------
>>>> ./ontonet/ontology/pizzaScope                     PUT {GET, POST, 
>>>> OPTIONS}
>>>> ./ontonet/ontology/pizzaScope                    DELETE {GET, POST, 
>>>> OPTIONS}
>>>
>>> I committed a modification in ontologymanager.web today, where the 
>>> PUT and DELETE methods are explicitly added on OPTIONS preflight 
>>> request. Don't know if this helps because I haven't been able to 
>>> test it. Does it work better for you?
>>
>> I just updated and rebuilt Stanbol, but I'm still getting 'Method not 
>> allowed' for the PUT and DELETE preflight requests.
>
> And if you make an OPTIONS request?
>
> It might help me if it does, as I don't quite dig CORS.
>
>> Did you make them appear in the Access-Control-Allow-Methods header?
>
> I don't have the tools at hand for figuring this out right now, that's 
> why I am asking. I am sorry for having to bother you.
>
> Best,
> -- alessandro
>
>

Re: Allow-Methods header

Posted by Alessandro Adamou <ad...@cs.unibo.it>.

On 7/2/12 8:35 PM, Melanie Reiplinger wrote:
>>> presently NOT-working:
>>> --------------------------------
>>> ./ontonet/ontology/pizzaScope                     PUT {GET, POST, 
>>> OPTIONS}
>>> ./ontonet/ontology/pizzaScope                    DELETE {GET, POST, 
>>> OPTIONS}
>>
>> I committed a modification in ontologymanager.web today, where the 
>> PUT and DELETE methods are explicitly added on OPTIONS preflight 
>> request. Don't know if this helps because I haven't been able to test 
>> it. Does it work better for you?
>
> I just updated and rebuilt Stanbol, but I'm still getting 'Method not 
> allowed' for the PUT and DELETE preflight requests.

And if you make an OPTIONS request?

It might help me if it does, as I don't quite dig CORS.

> Did you make them appear in the Access-Control-Allow-Methods header?

I don't have the tools at hand for figuring this out right now, that's 
why I am asking. I am sorry for having to bother you.

Best,
-- alessandro


-- 
M.Sc. Alessandro Adamou

Alma Mater Studiorum - Università di Bologna
Department of Computer Science
Mura Anteo Zamboni 7, 40127 Bologna - Italy

Semantic Technology Laboratory (STLab)
Institute for Cognitive Science and Technology (ISTC)
National Research Council (CNR)
Via Nomentana 56, 00161 Rome - Italy


"I will give you everything, just don't demand anything."
(Ettore Petrolini, 1917)

Not sent from my iSnobTechDevice

Re: Allow-Methods header

Posted by Melanie Reiplinger <me...@dfki.de>.

Hi Alessandro,

thanks for the fast reply.

Am 02.07.2012 18:36, schrieb Alessandro Adamou:
> Hi Melanie,
>
> On 6/29/12 12:12 PM, Melanie Reiplinger wrote:
>> <uri> <Access-Control-Request-Method> <Access-Control-Allow-Methods>
>>
>> presently working:
>> --------------------------
>> ./ontonet/ontology/pizzaScope            POST     (303 see other)
>
> I am probably going to change these, since 303 is mostly useful for 
> browsers only. For PUT or POST methods that create resources will 
> gradually be returning 201 CREATED, so hopefully this will help 
> declare Allow-Methods.
>
>> presently NOT-working:
>> --------------------------------
>> ./ontonet/ontology/pizzaScope                     PUT        {GET, 
>> POST, OPTIONS}
>> ./ontonet/ontology/pizzaScope                    DELETE    {GET, 
>> POST, OPTIONS}
>
> I committed a modification in ontologymanager.web today, where the PUT 
> and DELETE methods are explicitly added on OPTIONS preflight request. 
> Don't know if this helps because I haven't been able to test it. Does 
> it work better for you?

I just updated and rebuilt Stanbol, but I'm still getting 'Method not 
allowed' for the PUT and DELETE preflight requests.
Did you make them appear in the Access-Control-Allow-Methods header? 
Because the Access-Control-Allow-Methods that comes back from the server 
still contains only GET, POST and OPTIONS.

Access-Control-Allow-Methods:
GET, POST, OPTIONS


>
> BTW what tools are you using to figure out these method headers? curl 
> doesn't really say that much here.

I'm doing the requests from a small local server and test my Javascript 
interface methods in the Browser, so I can look at the requests in 
detail; in my case, using Chrome Developer Tools. It shows the request 
and response headers as well as the error messages that are returned.
I cannot test these things with curl, since all the requests always work 
when using curl. So what I do is the following: I try the requests with 
curl to check whether the request in principle works, and then I 
implement in jQuery and check via web Browser.

Best,
melanie

>
> Best regards
>
> alessandro
>
>
>> Am 27.06.2012 19:39, schrieb Rupert Westenthaler:
>>> Hi Melanie
>>>
>>> On Wed, Jun 27, 2012 at 3:04 PM, Melanie Reiplinger
>>> <me...@dfki.de>  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
>>>>>>> <me...@dfki.de>     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
>>>>>>>>> <me...@dfki.de>       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)
>>>>>>>>>>
>>>>>>>>>>
>>>
>>>
>>
>>
>
>

Re: Allow-Methods header

Posted by Alessandro Adamou <ad...@cs.unibo.it>.

Hi Melanie,

On 6/29/12 12:12 PM, Melanie Reiplinger wrote:
> <uri> <Access-Control-Request-Method> <Access-Control-Allow-Methods>
>
> presently working:
> --------------------------
> ./ontonet/ontology/pizzaScope            POST     (303 see other)

I am probably going to change these, since 303 is mostly useful for 
browsers only. For PUT or POST methods that create resources will 
gradually be returning 201 CREATED, so hopefully this will help declare 
Allow-Methods.

> presently NOT-working:
> --------------------------------
> ./ontonet/ontology/pizzaScope                     PUT        {GET, 
> POST, OPTIONS}
> ./ontonet/ontology/pizzaScope                    DELETE    {GET, POST, 
> OPTIONS}

I committed a modification in ontologymanager.web today, where the PUT 
and DELETE methods are explicitly added on OPTIONS preflight request. 
Don't know if this helps because I haven't been able to test it. Does it 
work better for you?

BTW what tools are you using to figure out these method headers? curl 
doesn't really say that much here.

Best regards

alessandro


> Am 27.06.2012 19:39, schrieb Rupert Westenthaler:
>> Hi Melanie
>>
>> On Wed, Jun 27, 2012 at 3:04 PM, Melanie Reiplinger
>> <me...@dfki.de>  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
>>>>>> <me...@dfki.de>     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
>>>>>>>> <me...@dfki.de>       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)
>>>>>>>>>
>>>>>>>>>
>>
>>
>
>


-- 
M.Sc. Alessandro Adamou

Alma Mater Studiorum - Università di Bologna
Department of Computer Science
Mura Anteo Zamboni 7, 40127 Bologna - Italy

Semantic Technology Laboratory (STLab)
Institute for Cognitive Science and Technology (ISTC)
National Research Council (CNR)
Via Nomentana 56, 00161 Rome - Italy


"I will give you everything, just don't demand anything."
(Ettore Petrolini, 1917)

Not sent from my iSnobTechDevice

Re: Allow-Methods header

Posted by Melanie Reiplinger <me...@dfki.de>.

Hi Rupert and all,

yes, right now it seems I have full CRUD access for the entityhub (on 
DFKI server) from my localhost 'across origins'.

I just checked the RESTful services I tried during the last weeks:
(I can report that on STANBOL-105 later on, if you want)

<uri> <Access-Control-Request-Method> <Access-Control-Allow-Methods>

presently working:
--------------------------
./entityhub/entity                        POST    {GET, POST, PUT, 
DELETE, OPTIONS}
./entityhub/entity?update=true            POST    {GET, POST, PUT, 
DELETE, OPTIONS}
./entityhub/entity?id=<id>&create=false    PUT         {GET, POST, PUT, 
DELETE, OPTIONS}
./entityhub/entity?id=<id>                DELETE    {GET, POST, PUT, 
DELETE, OPTIONS}
./contenthub/ldpath/program                POST    (ok)
./contenthub/<index>/store/<id>            POST    (ok)
./ontonet/ontology/pizzaScope            POST     (303 see other)

(entity/mapping ist trivial, weil nur GET)

presently NOT-working:
--------------------------------
./ontonet/ontology/pizzaScope                     PUT        {GET, POST, 
OPTIONS}
./ontonet/ontology/pizzaScope                    DELETE    {GET, POST, 
OPTIONS}
./contenthub/ldpath/program/<indexID>            DELETE
./contenthub/contenthub/store/raw/<id>            GET            (this 
is really strange, since the GET on 
./contenthub/contenthub/store/metadata/<id> works and a few weeks ago, 
both requests worked perfectly. So this might be a version issue with my 
code)






Am 27.06.2012 19:39, schrieb Rupert Westenthaler:
> Hi Melanie
>
> On Wed, Jun 27, 2012 at 3:04 PM, Melanie Reiplinger
> <me...@dfki.de>  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
>>>>> <me...@dfki.de>     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
>>>>>>> <me...@dfki.de>       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)
>>>>>>>>
>>>>>>>>
>
>

Re: Allow-Methods header

Posted by Rupert Westenthaler <ru...@gmail.com>.

Hi Melanie

On Wed, Jun 27, 2012 at 3:04 PM, Melanie Reiplinger
<me...@dfki.de> 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
>>>> <me...@dfki.de>   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
>>>>>> <me...@dfki.de>     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             rupert.westenthaler@gmail.com
| Bodenlehenstraße 11                             ++43-699-11108907
| A-5500 Bischofshofen

Re: Allow-Methods header

Posted by Melanie Reiplinger <me...@dfki.de>.

Hi Rupert.

Ok, I was on an older version. So I updated and rebuilt stanbol. Got it 
running only when specifying -XX:MaxPermSize=256m as option (128m was 
not enough).
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 :-)

 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
>>> <me...@dfki.de>   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
>>>>> <me...@dfki.de>     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)
>>>>>>
>>>>>>
>>>

Re: Allow-Methods header

Posted by Rupert Westenthaler <ru...@gmail.com>.

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
>> <me...@dfki.de>  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
>>>> <me...@dfki.de>    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)
>>>>> 
>>>>> 
>>>> 
>> 
>> 
>

Re: Allow-Methods header

Posted by Melanie Reiplinger <me...@dfki.de>.

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.

 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
> <me...@dfki.de>  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
>>> <me...@dfki.de>    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)
>>>>
>>>>
>>>
>
>

Re: Allow-Methods header

Posted by Rupert Westenthaler <ru...@gmail.com>.

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
<me...@dfki.de> 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
>> <me...@dfki.de>  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             rupert.westenthaler@gmail.com
| Bodenlehenstraße 11                             ++43-699-11108907
| A-5500 Bischofshofen

Re: Allow-Methods header

Posted by Melanie Reiplinger <me...@dfki.de>.

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
> <me...@dfki.de>  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)
>>
>>
>
>

Re: Allow-Methods header

Posted by Rupert Westenthaler <ru...@gmail.com>.

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
<me...@dfki.de> 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             rupert.westenthaler@gmail.com
| Bodenlehenstraße 11                             ++43-699-11108907
| A-5500 Bischofshofen