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
<[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)
