I am trying to use the method PUT for a REST service and I got an error:
curl -v -H "Content-Type: application/xml" -X PUT --data-binary "#putUsers.xml" http://localhost:8080/RestDB/webresources/User/5
The response is:
Trying ::1...
* Connected to localhost (::1) port 8080 (#0)
> PUT /RestDB/webresources/User/5 HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.46.0
> Accept: */*
> Content-Type: application/xml
> Content-Length: 409
>
* upload completely sent off: 409 out of 409 bytes
< HTTP/1.1 400 Bad Request
< Server: GlassFish Server Open Source Edition 4.1.1
< X-Powered-By: Servlet/3.1 JSP/2.3 (GlassFish Server Open Source Edition 4.1.1 Java/Oracle Corporation/1.8)
< Content-Language:
< Content-Type: text/html
< Date: Thu, 03 Aug 2017 09:55:13 GMT
< Connection: close
< Content-Length: 1109
<
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><title>GlassFish Server Open Source Edition 4.1.1 - Error report</title><style type="text/css"><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 400 - Bad Request</h1><hr/><p><b>type</b> Status report</p><p><b>message</b>Bad Request</p><p><b>description</b>The request sent by the client was syntactically incorrect.</p><hr/><h3>GlassFish Server Open Source Edition 4.1.1 </h3></body></html>* Closing connection 0
Server log:
Exception while deploying the app [RestDB] : Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.6.1.v20150605-31e8258): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLException: Error in allocating a connection. Cause: Connection could not be allocated because: Insufficient data while reading from the network - expected a minimum of 6 bytes and received only 0 bytes. The connection has been terminated.
Error Code: 0
I am trying to do update in the database.
Thanks a lot!
You are mixing to much things, please focus yourself and ask a proper question.
Obviously your app is not even deployed, so you don't need to try to send requests with curl, this cannot work.
Fix your problems step by step (if needed, ask several specific questions), the first step should be to deploy the application properly.
Related
I'm sending GET requests via proxy that only supports HTTP (no HTTPS support). When I use that proxy (or any other http-only proxy) to request HTTPS it returns 403 when I use curl (and it seems to be the correct status). But if I just use CONNECT and GET I get 200.
Curl - 403 Forbidden:
curl -x proxyhost:proxyport -I https://example.com -vvv
* Trying PROXYHOST:8080...
* TCP_NODELAY set
* Connected to PROXYHOST (PROXYHOST) port 8080 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to www.example.com:443
> CONNECT www.example.com:443 HTTP/1.1
> Host: www.example.com:443
> User-Agent: curl/7.68.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
< Date: Fri, 15 Oct 2021 15:37:31 GMT
Date: Fri, 15 Oct 2021 15:37:31 GMT
< Server: Apache
Server: Apache
< Content-Length: 202
Content-Length: 202
< Content-Type: text/html; charset=iso-8859-1
Content-Type: text/html; charset=iso-8859-1
<
* Received HTTP code 403 from proxy after CONNECT
* CONNECT phase completed!
* Closing connection 0
curl: (56) Received HTTP code 403 from proxy after CONNECT
Pure HTTP - 200 OK:
CONNECT PROXYHOST:PROXYPORT HTTP/1.0
GET https://www.example.com:443 HTTP/1.0
HTTP/1.0 200 OK
Why do I get 200 with CONNECT + GET?
Additional info:
PROXYHOST is just a random host without any proxy setting or software. It just happens so that when you use it as proxy for http GET requests it returns correct status (200 if requested page exists, 404 if it does not, etc) and its own html instead of requested body. At the same time it always returns 403 if you try to use it as proxy for requesting https via anything but CONNECT + GET.
I also tried python requests and got this result (with verbose logs):
proxy = {'https': 'http://PROXYHOST:8080', 'http': 'http://PROXYHOST:8080'}
requests.get('https://example.com', proxies=proxy)
# logs
send: b'CONNECT example.com:443 HTTP/1.0\r\n'
send: b'\r\n'
# exception
File "/usr/lib/python3.8/http/client.py", line 276, in _read_status
raise RemoteDisconnected("Remote end closed connection without"
http.client.RemoteDisconnected: Remote end closed connection without response / (Caused by ProxyError('Cannot connect to proxy.', RemoteDisconnected('Remote end closed connection without response')))
requests.get('http://example.com', proxies=proxy)
# logs
send: b'GET http://example.com/ HTTP/1.1\r\nHost: example.com\r\nUser-Agent: python-requests/2.25.0\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nConnection: keep-alive\r\n\r\n'
reply: 'HTTP/1.1 200 OK\r\n'
header: Date: Fri, 15 Oct 2021 17:10:00 GMT
header: ...
<Response [200]>
Well, this website uses AWS EC2, and right now when i shared the site on Facebook, facebook don't show nothing, but yesterday it work well.
Right now the Facebook lint(object debugger) says
Error parsing input URL, no data was cached, or no data was scraped.
And
Curl Error : RECV_ERROR Received HTTP code 502 from proxy after
CONNECT
But when i use curl via terminal on my Mac (like curl -v -X TRACE www.cuinzy.com) this return:
* Rebuilt URL to: www.cuinzy.com/
* Hostname was NOT found in DNS cache
* Trying 54.207.48.99...
* Connected to www.cuinzy.com (127.0.0.1) port 80 (#0)
> TRACE / HTTP/1.1
> User-Agent: curl/7.37.1
> Host: www.cuinzy.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 17 Aug 2015 10:14:36 GMT
* Server Apache is not blacklisted
< Server: Apache
< Connection: close
< Transfer-Encoding: chunked
< Content-Type: message/http
<
TRACE / HTTP/1.1
User-Agent: curl/7.37.1
Host: www.cuinzy.com
Accept: */*
* Closing connection 0
Curl return response code 200 on www.cuinzy.com, and if try with url https://www.cuinzy.com/itm/572-aumento-natural-del-busto-pueraria-mirifica-100-x-500mg.html, this return:
* Hostname was NOT found in DNS cache
* Trying 54.207.48.99...
* Connected to www.cuinzy.com (127.0.0.1) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
* Server certificate: *.cuinzy.com
* Server certificate: COMODO RSA Domain Validation Secure Server CA
* Server certificate: COMODO RSA Certification Authority
* Server certificate: AddTrust External CA Root
> TRACE /itm/572-aumento-natural-del-busto-pueraria-mirifica-100-x-500mg.html HTTP/1.1
> User-Agent: curl/7.37.1
> Host: www.cuinzy.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 17 Aug 2015 10:16:25 GMT
* Server Apache is not blacklisted
< Server: Apache
< Connection: close
< Transfer-Encoding: chunked
< Content-Type: message/http
<
TRACE /itm/572-aumento-natural-del-busto-pueraria-mirifica-100-x-500mg.html HTTP/1.1
User-Agent: curl/7.37.1
Host: www.cuinzy.com
Accept: */*
* Closing connection 0
And look how the use of SSL does not represent a change, additionally, notice that at all times the http response code is 200.
And, if i click on See exactly what our scraper sees for your URL link of Facebook Lint, this only return:
Document returned no data
Ah, additionally, i try this tools(and all return http response code 200 and work fine):
curl via terminal on mac
http://httpstatus.io/
http://iframely.com/debug?uri=https%3A%2F%2Fwww.cuinzy.com%2Fitm%2F572-aumento-natural-del-busto-pueraria-mirifica-100-x-500mg.html
http://opengraphcheck.com/result.php?url=https%3A%2F%2Fwww.cuinzy.com%2Fitm%2F572-aumento-natural-del-busto-pueraria-mirifica-100-x-500mg.html#.VdG3hVN_Oko
https://coveloping.com/tools/open-graph-tag-tester
Please, if you know whats happend tell me, i dont understand...
P.S: sorry for my bad english.
Using the latest development version:
I have registered a context provider for an attribute. When the attribute is asked the context provider is interrogated through a POST request which returns
curl -v --request POST http://130.206.83.68/ngsi10/queryContext
* About to connect() to 130.206.83.68 port 80 (#0)
* Trying 130.206.83.68... connected
> POST /ngsi10/queryContext HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: 130.206.83.68
> Accept: */*
>
< HTTP/1.1 200 OK
< X-Powered-By: Express
< Content-Type: application/json; charset=utf-8
< Content-Length: 206
< Date: Fri, 27 Mar 2015 11:09:05 GMT
< Connection: keep-alive
<
* Connection #0 to host 130.206.83.68 left intact
* Closing connection #0
{"contextResponses":[{"contextElement":
{"isPattern":false,"id":"Madrid","type":"Ciudad",
"attributes":[{"name":"population7","value":"6000","type":"string"}]},
"statusCode": {"code":200,"reasonPhrase":"OK"}}]}
However Orion does not recognize the response and the following trace appears:
INFO#10:59:36 clientSocketHttp.cpp[154]: Starting transaction to 130.206.83.68:80/ngsi10/queryContext
INFO#10:59:36 clientSocketHttp.cpp[364]: Notification Successfully Sent to 130.206.83.68:80/ngsi10/queryContext
INFO#10:59:36 clientSocketHttp.cpp[375]: Transaction ended
WARNING#10:59:36 postQueryContext.cpp[211]: Other Error (context provider response to QueryContext is empty)
INFO#10:59:36 rest.cpp[383]: Transaction ended
This problem is probably due to current Orion version (0.19.0) assumes always that the context providers implement XML rendering. Thus, if your context provider responses in JSON, Orion will not understand the response.
The solution is to implement XML in your context provider (or wait until Orion implement the proper mechanism).
I'm creating a REST interface (aren't we all), and I want to UPDATE a resource.
So, I think to use a PUT.
So, i read this.
My take away is that i PUT to a URL like this
/hc/api/v1/organizer/event/762d36c2-afc5-4c51-84eb-9b5b0ef2990c
with a payload, then a permanent redirect to the URL that it can GET an updated version of the resource.
In this case it happens to be the same URL, different action.
So my questions are:
Is my understanding of updating a resource correct in using a PUT, and is my understanding of the use of the PUT correct.
When a client gets a redirect does it do the same action on the redirected URL as it did on the original URL? If its "depends" is there a standard most clients follow?
I ask the 2nd question, because POSTMAN and my JQuery AJAX calls are choking. JQuery because of net::ERR_TOO_MANY_REDIRECTS. So is it redirecting and trying the PUT again, which it will get another REDIRECT?
curl blows up too but even though it says if it gets a 301 it will switch to a GET, it doesn't really seem to do that when i look at the output (below).
When curl follows a redirect and the request is not a plain GET (for example POST or PUT), it will do the following request with a GET if the HTTP response was 301, 302, or 303. If the response code was any other 3xx code, curl will re-send the following request using the same unmodified method.
CURL OUTPUT (edited for brevity) (also note how it says its going to switch to a GET [incorrectly from a POST], but then it seems to do a PUT anyway):
curl -X PUT -H "Authorization: Basic AUTHZ==" -H "Content-Type: application/json" -H "Cache-Control: no-cache" -H "Postman-Token: e80657f0-a8f5-af77-1d9d-d7bc22ed0b30" -d '{ JSONDATA"}' http://localhost:8080/hc/api/v1/organizer/event/762d36c2-afc5-4c51-84eb-9b5b0ef2990c -v -L
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> PUT /hc/api/v1/organizer/event/762d36c2-afc5-4c51-84eb-9b5b0ef2990c HTTP/1.1
> User-Agent: curl/7.37.1
> Host: localhost:8080
> Accept: */*
> Authorization: Basic AUTHZ==
> Content-Type: application/json
> Cache-Control: no-cache
> Postman-Token: e80657f0-a8f5-af77-1d9d-d7bc22ed0b30
> Content-Length: 203
>
* upload completely sent off: 203 out of 203 bytes
< HTTP/1.1 301 Moved Permanently
< Connection: keep-alive
< X-Powered-By: Undertow/1
< Set-Cookie: rememberMe=deleteMe; Path=/hc; Max-Age=0; Expires=Fri, 20-Feb-2015 03:53:28 GMT
< Set-Cookie: JSESSIONID=uwI3_41LAa7vlvapTsrZdw10.macbook-air; path=/hc
* Server WildFly/8 is not blacklisted
< Server: WildFly/8
< Location: /hc/api/v1/organizer/event/762d36c2-afc5-4c51-84eb-9b5b0ef2990c
< Content-Length: 0
< Date: Sat, 21 Feb 2015 03:53:28 GMT
<
* Connection #0 to host localhost left intact
* Issue another request to this URL: 'http://localhost:8080/hc/api/v1/organizer/event/762d36c2-afc5-4c51-84eb-9b5b0ef2990c'
* Switch from POST to GET
* Found bundle for host localhost: 0x7f9e4b415430
* Re-using existing connection! (#0) with host localhost
* Connected to localhost (127.0.0.1) port 8080 (#0)
> PUT /hc/api/v1/organizer/event/762d36c2-afc5-4c51-84eb-9b5b0ef2990c HTTP/1.1
> User-Agent: curl/7.37.1
> Host: localhost:8080
> Accept: */*
> Authorization: Basic dGVzdHVzZXIxOlBhc3N3b3JkMQ==
> Content-Type: application/json
> Cache-Control: no-cache
> Postman-Token: e80657f0-a8f5-af77-1d9d-d7bc22ed0b30
>
< HTTP/1.1 500 Internal Server Error
< Connection: keep-alive
< Set-Cookie: JSESSIONID=fDXxlH2xI-0-DEaC6Dj5EhD9.macbook-air; path=/hc
< Content-Type: text/html; charset=UTF-8
< Content-Length: 8593
< Date: Sat, 21 Feb 2015 03:53:28 GMT
<
...failure ensues... It actually does a PUT
thanks in advance.
I think you're reading too much into the 301 redirect section.
If you want to update a resource using PUT, return:
201: if the resource was created
200: with the updated resource
The 301 in question only applies if there actually is a redirect in question - like, if something can be identified by name, and you need to redirect it to a url that has the id or something. (Maybe you refactor and people are still consuming the old endpoint).
So, do you really need to redirect your PUT requests? Because you should be sending back the updated resource within the same loop using 200, like stated above, instead of "redirecting to GET".
EDIT: Fix some spelling.
consider a web service written in play, which excepts POST request (for uploads). now, when testing this with a medium size image (~75K) I've found out a strange behaviour. well, code speaks more clearly than long explanations, so:
$ curl -vX POST localhost:9000/path/to/upload/API -H "Content-Type: image/jpeg" -d #/path/to/mascot.jpg
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 9000 (#0)
> POST /path/to/upload/API HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:9000
> Accept: */*
> Content-Type: image/jpeg
> Content-Length: 27442
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< Content-Length: 16
<
* Connection #0 to host localhost left intact
{"success":true}
as you can see, curl decides to add the header Content-Length: 27442, but it's not true, the real size is 75211, and in play, I indeed got a body in size only 27442. of coarse, this is not the intended behaviour. so I tried a different tool, instead of curl I used the POST tool from libwww-perl:
cat /path/to/mascot.jpg | POST -uUsSeE -c image/jpeg http://localhost:9000/path/to/upload/API
POST http://localhost:9000/path/to/upload/API
User-Agent: lwp-request/6.03 libwww-perl/6.05
Content-Length: 75211
Content-Type: image/jpeg
200 OK
Content-Length: 16
Content-Type: application/json; charset=utf-8
Client-Date: Mon, 16 Jun 2014 09:21:00 GMT
Client-Peer: 127.0.0.1:9000
Client-Response-Num: 1
{"success":true}
this request succeeded. so I started to pay more attention to the differences between the tools. for starter: the Content-Length header was correct, but also, the Expect header was missing from the second try. I want the request to succeed either way. so the full list of headers as seen in play (via request.headers) is:
for curl:
ArrayBuffer((Content-Length,ArrayBuffer(27442)),
(Accept,ArrayBuffer(*/*)),
(Content-Type,ArrayBuffer(image/jpeg)),
(Expect,ArrayBuffer(100-continue)),
(User-Agent,ArrayBuffer(curl/7.35.0)),
(Host,ArrayBuffer(localhost:9000)))
for the libwww-perl POST:
ArrayBuffer((TE,ArrayBuffer(deflate,gzip;q=0.3)),
(Connection,ArrayBuffer(TE, close)),
(Content-Length,ArrayBuffer(75211)),
(Content-Type,ArrayBuffer(image/jpeg)),
(User-Agent,ArrayBuffer(lwp-request/6.03 libwww-perl/6.05)),
(Host,ArrayBuffer(localhost:9000)))
So my current thoughts are: the simpler perl tool used a single request, which is bad practice. the better way would be to wait for a 100 continue confirmation (especially if you gonna' upload a several GB of data...). curl would continue to send data until it receives a 200 OK or some bad request error code. So why play sends the 200 OK response without waiting for the next chunk? is it because curl specifies the wrong Content-Length? if it's wrong at all... (perhaps this refers to the size of the current chunk?).
so where's the problem lies? in curl or in the play webapp? and how do I fix it?
the problem was in my curl command. I used the -d argument, which is a short for --data or --data-ascii, when I should have used --data-binary argument.