I am using FOSRestBundle.
I am using a GET request and I am expecting an 404 error message, but it is very long.
Here is the definition of the action() method:
/**
* #Rest\View
* #Rest\Get("/api/test/{id}",
* requirements={"id" = "\d+"},
* defaults={"id" = 1}
* )
*/
public function getAction($id) {
$repo = $this->getDoctrine()->
getManager()->
getRepository("MinnAdsAPIBundle:Test");
$entity = $repo->find($id);
if (!$entity) {
throw $this->createNotFoundException('Unable to find test entity!');
}
return array('test' => $entity);
}
To check the request, I used this shell command: curl -i http://localhost/tuto/web/app_dev.php/api/test/16654
The result is:
HTTP/1.1 404 Not Found
Date: Fri, 11 Apr 2014 07:33:13 GMT
Server: Apache/2.2.22 (Ubuntu)
X-Powered-By: PHP/5.4.9-4ubuntu2.4
Set-Cookie: PHPSESSID=r5fjnf14fp0oou8ac8hu60vru7; path=/
Cache-Control: no-cache
Vary: Accept-Language
X-Debug-Token: 97fd81
Transfer-Encoding: chunked
Content-Type: application/json
[{"message":"Unable to find test entity!","class":"Symfony\\Component\\HttpKernel\\Exception\\NotFoundHttpException","trace":[{"namespace":"","short_class":"","class":"","type":"","function":"","file":"\/home\/amine\/NetBeansProjects\/tuto\/vendor\/symfony\/symfony\/src\/Symfony\/Bundle\/FrameworkBundle\/Controller\/Controller.php","line":149,"args":[]},{"namespace":"Symfony\\Bundle\\FrameworkBundle\\Controller","short_class":"Controller","class":"Symfony\\Bundle\\FrameworkBundle\\Controller\\Controller","type":"->","function":"createNotFoundException","file":"\/home\/amine\/NetBeansProjects\/tuto\/src\/Minn\/AdsAPIBundle\/Controller\/TestController.php","line":31,"args":[["string","Unable to find test entity!"]]},{"namespace":"Minn\\AdsAPIBundle\\Controller","short_class":"TestController","class":"Minn\\AdsAPIBundle\\Controller\\TestController","type":"->","function":"getAction","file":null,"line":null,"args":[["string","155"]]},{"namespace":"","short_class":"","class":"","type":"","function":"call_user_func_array","file":"\/home\/amine\/NetBeansProjects\/tuto\/app\/bootstrap.php.cache","line":2841,"args":[["array",[["object","Minn\\AdsAPIBundle\\Controller\\TestController"],["string","getAction"]]],["array",[["string","155"]]]]},{"namespace":"Symfony\\Component\\HttpKernel","short_class":"HttpKernel","class":"Symfony\\Component\\HttpKernel\\HttpKernel","type":"->","function":"handleRaw","file":"\/home\/amine\/NetBeansProjects\/tuto\/app\/bootstrap.php.cache","line":2815,"args":[["object","Symfony\\Component\\HttpFoundation\\Request"],["string","1"]]},{"namespace":"Symfony\\Component\\HttpKernel","short_class":"HttpKernel","class":"Symfony\\Component\\HttpKernel\\HttpKernel","type":"->","function":"handle","file":"\/home\/amine\/NetBeansProjects\/tuto\/app\/bootstrap.php.cache","line":2944,"args":[["object","Symfony\\Component\\HttpFoundation\\Request"],["string","1"],["boolean",true]]},{"namespace":"Symfony\\Component\\HttpKernel\\DependencyInjection","short_class":"ContainerAwareHttpKernel","class":"Symfony\\Component\\HttpKernel\\DependencyInjection\\ContainerAwareHttpKernel","type":"->","function":"handle","file":"\/home\/amine\/NetBeansProjects\/tuto\/app\/bootstrap.php.cache","line":2245,"args":[["object","Symfony\\Component\\HttpFoundation\\Request"],["string","1"],["boolean",true]]},{"namespace":"Symfony\\Component\\HttpKernel","short_class":"Kernel","class":"Symfony\\Component\\HttpKernel\\Kernel","type":"->","function":"handle","file":"\/home\/amine\/NetBeansProjects\/tuto\/web\/app_dev.php","line":29,"args":[["object","Symfony\\Component\\HttpFoundation\\Request"]]}]}]
The message I am expecting is:
HTTP/1.1 404 Not Found
Date: Fri, 11 Apr 2014 07:33:13 GMT
Server: Apache/2.2.22 (Ubuntu)
X-Powered-By: PHP/5.4.9-4ubuntu2.4
Set-Cookie: PHPSESSID=r5fjnf14fp0oou8ac8hu60vru7; path=/
Cache-Control: no-cache
Vary: Accept-Language
X-Debug-Token: 97fd81
Transfer-Encoding: chunked
Content-Type: application/json
{"message":"Unable to find test entity!"}
Is there any idea to achieve that?
thanks,
#amine put in your terminal this commande:
curl -i http://localhost/tutonew/web/api/test/16654
!!!
Related
I have a Java client, that is making a POST call to the v1/graphql endpoint of a Hasura server (v1.3.3)
I'm making the HTTP call using the Square okhttp3 library (v4.9.1). The data transfer is happening over HTTP1.1, using chunked transfer-encoding.
The client is failing with the following error:
Caused by: java.net.ProtocolException: unexpected end of stream
at okhttp3.internal.http1.Http1ExchangeCodec$ChunkedSource.read(Http1ExchangeCodec.kt:415) ~[okhttp-4.9.1.jar:?]
at okhttp3.internal.connection.Exchange$ResponseBodySource.read(Exchange.kt:276) ~[okhttp-4.9.1.jar:?]
at okio.RealBufferedSource.read(RealBufferedSource.kt:189) ~[okio-jvm-2.8.0.jar:?]
at okio.RealBufferedSource.exhausted(RealBufferedSource.kt:197) ~[okio-jvm-2.8.0.jar:?]
at okio.InflaterSource.refill(InflaterSource.kt:112) ~[okio-jvm-2.8.0.jar:?]
at okio.InflaterSource.readOrInflate(InflaterSource.kt:76) ~[okio-jvm-2.8.0.jar:?]
at okio.InflaterSource.read(InflaterSource.kt:49) ~[okio-jvm-2.8.0.jar:?]
at okio.GzipSource.read(GzipSource.kt:69) ~[okio-jvm-2.8.0.jar:?]
at okio.Buffer.writeAll(Buffer.kt:1642) ~[okio-jvm-2.8.0.jar:?]
at okio.RealBufferedSource.readString(RealBufferedSource.kt:95) ~[okio-jvm-2.8.0.jar:?]
at okhttp3.ResponseBody.string(ResponseBody.kt:187) ~[okhttp-4.9.1.jar:?]
Request Headers:
INFO: Content-Type: application/json; charset=utf-8
INFO: Content-Length: 1928
INFO: Host: localhost:10191
INFO: Connection: Keep-Alive
INFO: Accept-Encoding: gzip
INFO: User-Agent: okhttp/4.9.1
Response headers:
INFO: Transfer-Encoding: chunked
INFO: Date: Tue, 27 Apr 2021 12:06:39 GMT
INFO: Server: Warp/3.3.10
INFO: x-request-id: d019408e-e2e3-4583-bcd6-050d4a496b11
INFO: Content-Type: application/json; charset=utf-8
INFO: Content-Encoding: gzip
This is the client code used for the making the POST call:
private static final MediaType MEDIA_TYPE_JSON = MediaType.parse("application/json; charset=utf-8");
private static OkHttpClient okHttpClient = new OkHttpClient.Builder()
.connectTimeout(30, TimeUnit.SECONDS)
.writeTimeout(5, TimeUnit.MINUTES)
.readTimeout(5, TimeUnit.MINUTES)
.addNetworkInterceptor(loggingInterceptor)
.build();
public GenericHttpResponse httpPost(String url, String textBody, GenericHttpMediaType genericMediaType) throws HttpClientException {
RequestBody body = RequestBody.create(okHttpMediaType, textBody);
Request postRequest = new Request.Builder().url(url).post(body).build();
Call postCall = okHttpClient.newCall(okHttpRequest);
Response postResponse = postCall.execute();
return GenericHttpResponse
.builder()
.body(okHttpResponse.body().string())
.headers(okHttpResponse.headers().toMultimap())
.code(okHttpResponse.code())
.build();
}
This failure is only happening for large response sizes. As per the server logs, the response size (after gzip encoding) is around 52MB, but the call is still failing. This same code has been working fine for response sizes around 10-15MB.
I tried replicating the same issue through a simple cURL call, but that ran successfully:
curl -v -s --request POST 'http://<hasura_endpoint>/v1/graphql' \
--header 'Content-Type: application/json' \
--header 'Accept-Encoding: gzip, deflate, br' \
--data-raw '...'
* Trying ::1...
* TCP_NODELAY set
* Connected to <host> (::1) port <port> (#0)
> POST /v1/graphql HTTP/1.1
> Host: <host>:<port>
> User-Agent: curl/7.64.1
> Accept: */*
> Content-Type: application/json
> Accept-Encoding: gzip, deflate, br
> Content-Length: 1840
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
} [1840 bytes data]
* We are completely uploaded and fine
< HTTP/1.1 200 OK
< Transfer-Encoding: chunked
< Date: Tue, 27 Apr 2021 11:59:24 GMT
< Server: Warp/3.3.10
< x-request-id: 27e3ff3f-8b95-4328-a1bc-a5492e68f995
< Content-Type: application/json; charset=utf-8
< Content-Encoding: gzip
<
{ [6 bytes data]
* Connection #0 to host <host> left intact
* Closing connection 0
So I'm assuming that this error is specific to the Java client.
Based on suggestions provided in similar posts, I tried the following other approaches:
Adding a Connection: close header to the request
Sending Transfer-Encoding: gzip header in the request
Setting the retryOnConnectionFailure for the OkHttp client to true
But none of these approaches were able to resolve the issue.
So, my questions are:
What could be the underlying cause for this issue? Since I'm using chunked transfer encoding here, I suppose it's not due to an incorrect content-length header passed in the response.
What are the approaches I can try for debugging this further?
Would really appreciate any insights on this. Thank you.
Hello I did run curl command and equal telnet command but response is different.
I try to get HTTP HEADER response code from a web server.
curl returns correct response, page indeed doesn't exist. But telnet with equal request return different response.
Please see CURL code:
$ curl -vI "https://www.abcanchorage.org/not-exist-page-con2uiu28itact"
* About to connect() to www.abcanchorage.org port 443 (#0)
* Trying 185.230.63.96...
* Connected to www.abcanchorage.org (185.230.63.96) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=abcanchorage.org
* start date: Nov 09 17:32:52 2020 GMT
* expire date: Feb 07 17:32:52 2021 GMT
* common name: abcanchorage.org
* issuer: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US
> HEAD /not-exist-page-con2uiu28itact HTTP/1.1
> User-Agent: curl/7.29.0
> Host: www.abcanchorage.org
> Accept: */*
>
< HTTP/1.1 404 Not Found
HTTP/1.1 404 Not Found
< Date: Mon, 14 Dec 2020 14:06:25 GMT
Date: Mon, 14 Dec 2020 14:06:25 GMT
< Content-Type: text/html; charset=UTF-8
Content-Type: text/html; charset=UTF-8
< Connection: keep-alive
Connection: keep-alive
< content-language: en
content-language: en
< x-wix-request-id: 1607954785.82658627446080423994
x-wix-request-id: 1607954785.82658627446080423994
< Age: 0
Age: 0
< Server-Timing: cache;desc=miss, varnish;desc=miss, dc;desc=84
Server-Timing: cache;desc=miss, varnish;desc=miss, dc;desc=84
< X-Seen-By: r5KTLwzxoi1C+SXup0UeuQ==,sHU62EDOGnH2FBkJkG/Wx8EeXWsWdHrhlvbxtlynkVg1leqePNkwQ1H/U0dj1nMN,2d58ifebGbosy5xc+FRalthBvkD9LHf+OIny1MrcDwiq6+5o8xu+S2UUMqtKcebjUMQY1HiUPm50af1ZAsGkCw==,2UNV7KOq4oGjA5+PKsX47Gzh5saLoQp8TIRIohc0Wac=,m0j2EEknGIVUW/liY8BLLuvhI/meCohDY7RevwAJ7JU=,w4q8mm9FnmU4emOs6psVXTk8VV0IpMOWw3zRTVWAPzKTzRA6xkSHdTdM1EufzDIPWIHlCalF7YnfvOr2cMPpyw==,8OhaUUQpIrZVCQED4XmuQ40tjCf+ijnQjDvVBuKrqCUYXyC7l2oN0jRBomMsk5tniLmOBCJX9PwPq0FFNfh5cw==
X-Seen-By: r5KTLwzxoi1C+SXup0UeuQ==,sHU62EDOGnH2FBkJkG/Wx8EeXWsWdHrhlvbxtlynkVg1leqePNkwQ1H/U0dj1nMN,2d58ifebGbosy5xc+FRalthBvkD9LHf+OIny1MrcDwiq6+5o8xu+S2UUMqtKcebjUMQY1HiUPm50af1ZAsGkCw==,2UNV7KOq4oGjA5+PKsX47Gzh5saLoQp8TIRIohc0Wac=,m0j2EEknGIVUW/liY8BLLuvhI/meCohDY7RevwAJ7JU=,w4q8mm9FnmU4emOs6psVXTk8VV0IpMOWw3zRTVWAPzKTzRA6xkSHdTdM1EufzDIPWIHlCalF7YnfvOr2cMPpyw==,8OhaUUQpIrZVCQED4XmuQ40tjCf+ijnQjDvVBuKrqCUYXyC7l2oN0jRBomMsk5tniLmOBCJX9PwPq0FFNfh5cw==
< Cache-Control: no-cache
Cache-Control: no-cache
< Vary: Accept-Encoding
Vary: Accept-Encoding
< Transfer-Encoding: chunked
Transfer-Encoding: chunked
<
* Connection #0 to host www.abcanchorage.org left intact
Please see TELNET code:
$ telnet www.abcanchorage.org 80
Trying 35.246.6.109...
Connected to www.abcanchorage.org.
Escape character is '^]'.
HEAD /not-exist-page-con2uiu28itact HTTP/1.1
User-Agent: curl/7.29.0
Host: www.abcanchorage.org
Accept: */*
HTTP/1.1 301 Moved Permanently
Date: Mon, 14 Dec 2020 14:08:50 GMT
Content-Length: 0
Connection: keep-alive
location: https://www.abcanchorage.org/not-exist-page-con2uiu28itact
Age: 1496
Server-Timing: cache;desc=hit, varnish;desc=hit, dc;desc=euw2
X-Seen-By: sHU62EDOGnH2FBkJkG/Wx8EeXWsWdHrhlvbxtlynkVgmNySqidgeEPHXBvm3U9iS,2d58ifebGbosy5xc+FRalhEF/w8i5SZb0AgDKvjhMuBVlHGeDiRYk3btR6xZR3zaGgqFbFMYwiXnFojPwdof6LPb61OjwxlOgfM3AWuO4IQ=,2UNV7KOq4oGjA5+PKsX47LZ7Kls+1whC/C/a0aUIqJE=
Cache-Control: no-cache
Expires: -1
X-Wix-Request-Id: 1607954930.2811039255969122439
Server: Pepyaka/1.19.0
^]quit
telnet> quit
Connection closed.
I am trying to authenticate my local Windows 10 machine to a web service running inside a docker container. To be more specific, this container is running Hadoop services and a MIT Kerberos KDC. I have installed MIT Kerberos for Windows on my local machine and have successfully gotten a ticket hadoop/quickstart.cloudera#CLOUDERA from the KDC. When I authenticate with the same principal inside my container and call this command: curl -i --negotiate -u : "http://quickstart.cloudera:50070/webhdfs/v1/?op=GETFILESTATUS" I get a valid response. However, the same command run from my Windows machine returns this error:
Error 403 GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
Can anyone familiar with SSPI/GSSAPI give me some insight on what the problem here could be?
I have the environment variable KRB5CCNAME=<path to ccache> set correctly. This is the cURL info from my Windows command prompt:
curl 7.52.1 (x86_64-w64-mingw32) libcurl/7.52.1 WinSSL zlib/1.2.8 WinIDN libssh2/1.7.0_DEV
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz
Let me know if you need any more information about my environment setup.
Update:
Here is the full HTTP response from my Windows machine when I run the command with the -v flag added for verbosity.
* timeout on name lookup is not supported
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to quickstart.cloudera (127.0.0.1) port 50070 (#0)
> GET /webhdfs/v1/?op=GETFILESTATUS HTTP/1.1
> Host: quickstart.cloudera:50070
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 401 Authentication required
HTTP/1.1 401 Authentication required
< Cache-Control: must-revalidate,no-cache,no-store
Cache-Control: must-revalidate,no-cache,no-store
< Date: Fri, 10 Feb 2017 19:41:27 GMT
Date: Fri, 10 Feb 2017 19:41:27 GMT
< Pragma: no-cache
Pragma: no-cache
< Date: Fri, 10 Feb 2017 19:41:27 GMT
Date: Fri, 10 Feb 2017 19:41:27 GMT
< Pragma: no-cache
Pragma: no-cache
< Content-Type: text/html; charset=iso-8859-1
Content-Type: text/html; charset=iso-8859-1
< WWW-Authenticate: Negotiate
WWW-Authenticate: Negotiate
< Set-Cookie: hadoop.auth=; Path=/; HttpOnly
Set-Cookie: hadoop.auth=; Path=/; HttpOnly
< Content-Length: 1404
Content-Length: 1404
< Server: Jetty(6.1.26.cloudera.4)
Server: Jetty(6.1.26.cloudera.4)
<
* Ignoring the response-body
* Curl_http_done: called premature == 0
* Connection #0 to host quickstart.cloudera left intact
* Issue another request to this URL: 'http://quickstart.cloudera:50070/webhdfs/v1/?op=GETFILESTATUS'
* Found bundle for host quickstart.cloudera: 0x817220 [can pipeline]
* Re-using existing connection! (#0) with host quickstart.cloudera
* Connected to quickstart.cloudera (127.0.0.1) port 50070 (#0)
* Server auth using Negotiate with user ''
> GET /webhdfs/v1/?op=GETFILESTATUS HTTP/1.1
> Host: quickstart.cloudera:50070
> Authorization: Negotiate TlRMTVNTUAABAAAAt4II4gAAAAAAAAAAAAAAAAAAAAAKAFopAAAADw==
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 403 GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
HTTP/1.1 403 GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
< Cache-Control: must-revalidate,no-cache,no-store
Cache-Control: must-revalidate,no-cache,no-store
< Date: Fri, 10 Feb 2017 19:41:27 GMT
Date: Fri, 10 Feb 2017 19:41:27 GMT
< Pragma: no-cache
Pragma: no-cache
< Date: Fri, 10 Feb 2017 19:41:27 GMT
Date: Fri, 10 Feb 2017 19:41:27 GMT
< Pragma: no-cache
Pragma: no-cache
< Content-Type: text/html; charset=iso-8859-1
Content-Type: text/html; charset=iso-8859-1
< Set-Cookie: hadoop.auth=; Path=/; HttpOnly
Set-Cookie: hadoop.auth=; Path=/; HttpOnly
< Content-Length: 1546
Content-Length: 1546
< Server: Jetty(6.1.26.cloudera.4)
Server: Jetty(6.1.26.cloudera.4)
<
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
<title>Error 403 GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)</title>
</head>
<body><h2>HTTP ERROR 403</h2>
<p>Problem accessing /webhdfs/v1/. Reason:
<pre> GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)</pre></p><hr /><i><small>Powered by Jetty://</small></i><br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
</body>
</html>
* Curl_http_done: called premature == 0
* Closing connection 0
In contrast, this is the response from running the same command inside my container:
* About to connect() to quickstart.cloudera port 50070 (#0)
* Trying 172.18.0.2... connected
* Connected to quickstart.cloudera (172.18.0.2) port 50070 (#0)
> GET /webhdfs/v1/?op=GETFILESTATUS HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: quickstart.cloudera:50070
> Accept: */*
>
< HTTP/1.1 401 Authentication required
HTTP/1.1 401 Authentication required
< Cache-Control: must-revalidate,no-cache,no-store
Cache-Control: must-revalidate,no-cache,no-store
< Date: Fri, 10 Feb 2017 21:15:39 GMT
Date: Fri, 10 Feb 2017 21:15:39 GMT
< Pragma: no-cache
Pragma: no-cache
< Date: Fri, 10 Feb 2017 21:15:39 GMT
Date: Fri, 10 Feb 2017 21:15:39 GMT
< Pragma: no-cache
Pragma: no-cache
< Content-Type: text/html; charset=iso-8859-1
Content-Type: text/html; charset=iso-8859-1
< WWW-Authenticate: Negotiate
WWW-Authenticate: Negotiate
< Set-Cookie: hadoop.auth=; Path=/; HttpOnly
Set-Cookie: hadoop.auth=; Path=/; HttpOnly
< Content-Length: 1404
Content-Length: 1404
< Server: Jetty(6.1.26.cloudera.4)
Server: Jetty(6.1.26.cloudera.4)
<
* Ignoring the response-body
* Connection #0 to host quickstart.cloudera left intact
* Issue another request to this URL: 'http://quickstart.cloudera:50070/webhdfs/v1/?op=GETFILESTATUS'
* Re-using existing connection! (#0) with host quickstart.cloudera
* Connected to quickstart.cloudera (172.18.0.2) port 50070 (#0)
* Server auth using GSS-Negotiate with user ''
> GET /webhdfs/v1/?op=GETFILESTATUS HTTP/1.1
> Authorization: Negotiate YIICkQYJKoZIhvcSAQICAQBuggKAMIICfKADAgEFoQMCAQ6iBwMFAAAAAACjggGBYYIBfTCCAXmgAwIBBaEKGwhDTE9VREVSQaImMCSgAwIBA6EdMBsbBEhUVFAbE3F1aWNrc3RhcnQuY2xvdWRlcmGjggE8MIIBOKADAgESoQMCAQKiggEqBIIBJnWbXp9WlAVk0nGIqD7T25On1+OCPzXDX/aoH01FTjJbEwrYj4cMML7Tf6jaKDIANEh57kTJOvPknL3CWHI1c3LeNpt1Ir8H2M3Zvk91HpbWXzv5WJTeUOK9L6zTaKFEs/dKQgD7VzmHKDJtMyVKQWLLVU8JuyKAV6iM4FvxfZ+WDF8QCk7pxwjgX1OT7jv9jR28MPpsIweqUYYnneJxVTsxgmsHdOvj5wpMGy9RA9R8jtR+Wh3l5r3a3zcUTmGwAqY+NXhBkviSTw+DgitnipYh5tXBRhNqGfk86qWAdodGgL+SdkwwGsq91PyYQiMCLXjWx90aBOEFeZLDyqBaXlMIZ3TT3urUQEuB206+8KNw1n6N6+u+ZY4QT7NJyVZqHbnOR5V5maSB4TCB3qADAgESooHWBIHTyaBY3PormkycaX9uf/lLe6ISYnItZikJqslAGpJVnla2HXYvhFjqn5yr8td1pw3zzdnDEZx3a9EylIrRQD5IoIvHCzd0mlJhHFj4xxISM5hxlMiL8DewMjGsVcDveqpHw1SyxIsrEPOhe62HuRXS7c1Z9kYkP6KldzyAJOttOVYCuL36hOxwEFqJtbWk1/f9gfTdzmxQmEASM3/wsj2Q/WYCZY/hazDIz6dmHsyla/F6NXGK0BwRnHHBCqSHe7GdWmBDNjHiuo6R0/YvqTl5Uvf0Rw==
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: quickstart.cloudera:50070
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Cache-Control: no-cache
Cache-Control: no-cache
< Expires: Fri, 10 Feb 2017 21:15:39 GMT
Expires: Fri, 10 Feb 2017 21:15:39 GMT
< Date: Fri, 10 Feb 2017 21:15:39 GMT
Date: Fri, 10 Feb 2017 21:15:39 GMT
< Pragma: no-cache
Pragma: no-cache
< Expires: Fri, 10 Feb 2017 21:15:39 GMT
Expires: Fri, 10 Feb 2017 21:15:39 GMT
< Date: Fri, 10 Feb 2017 21:15:39 GMT
Date: Fri, 10 Feb 2017 21:15:39 GMT
< Pragma: no-cache
Pragma: no-cache
< Content-Type: application/json
Content-Type: application/json
< Set-Cookie: hadoop.auth="u=hadoop&p=hadoop/quickstart.cloudera#CLOUDERA&t=kerberos&e=1486797339425&s=BqBHGJ+/FxxeSR0ayBXHOrfPkwU="; Path=/; HttpOnly
Set-Cookie: hadoop.auth="u=hadoop&p=hadoop/quickstart.cloudera#CLOUDERA&t=kerberos&e=1486797339425&s=BqBHGJ+/FxxeSR0ayBXHOrfPkwU="; Path=/; HttpOnly
< Transfer-Encoding: chunked
Transfer-Encoding: chunked
< Server: Jetty(6.1.26.cloudera.4)
Server: Jetty(6.1.26.cloudera.4)
<
* Connection #0 to host quickstart.cloudera left intact
* Closing connection #0
{"FileStatus":{"accessTime":0,"blockSize":0,"childrenNum":5,"fileId":16385,"group":"supergroup","length":0,"modificationTime":1459909590753,"owner":"hdfs","pathSuffix":"","permission":"755","replication":0,"storagePolicy":0,"type":"DIRECTORY"}}
The answer is very easy in this case. Curl on Windows is compiled with SSPI. When SSPI is requested to perform SPNEGO, it tries Kerberos, which fails here. Likely "Server not found in database" (use Wireshark) and then falls back to NTLM. It sends a raw NTLM token to your JGSS-backed server which rejects the token because
This is not a SPNEGO wrapped token, but a raw NTLM token
Java does not support NTLM
Here is sample code how to intercept this and respond with a meaningful message. Raise an issue with Hadoop.
Moreover, your Curl version 7.19.7 on Linux is extremely old and unsecure, you should upgrade immediately AND the SPNEGO Authenticator on Jetty is broken because it does not respond with a context-completion token. To sum up, the entire authentication should not be trusted because it is faulty. See RFC 7546.
I will be sending simple data to a web server, most probably just as a GET request which will be:
Latitude
Longitude
Speed
Height
deviceId
I could do this via SSH I suppose if it uses less data - but I cant see this being much.
So if i send this in myurl.com/parsedata.php?id=1&.... etc, how much data will it send require per request? the page will not load anything and it will do it over cURL or a similar protocol.
So, typically how much data will be in this per single request?
Thanks.
You can simply run curl from the command line with -v option for verbose output and see the data which goes to the server and back. Here is what I get when I do a curl on this question's URL:
curl http://stackoverflow.com/questions/31789124/how-much-data-is-in-one-curl-request -v
* Hostname was NOT found in DNS cache
* Trying 104.16.103.85...
* Connected to stackoverflow.com (104.16.103.85) port 80 (#0)
> GET /questions/31789124/how-much-data-is-in-one-curl-request HTTP/1.1
> User-Agent: curl/7.35.0
> Host: stackoverflow.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Tue, 04 Aug 2015 08:51:53 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=d89a0800ec97e30cad4dedad83d88e8dd1438678312; expires=Wed, 03-Aug-16 08:51:52 GMT; path=/; domain=.stackoverflow.com; HttpOnly
< Cache-Control: public, no-cache="Set-Cookie", max-age=60
< Cf-Railgun: 5107f6033d 18.60 0.037768 0030 4701
< Expires: Tue, 04 Aug 2015 08:52:53 GMT
< Last-Modified: Tue, 04 Aug 2015 08:51:53 GMT
< Vary: *
< X-Frame-Options: SAMEORIGIN
< X-Request-Guid: 3f5aca8a-2715-4fcf-b68b-f71f85a620e0
< Set-Cookie: prov=fcd7db27-9d37-4235-afb6-5c3d76dc03f5; domain=.stackoverflow.com; expires=Fri, 01-Jan-2055 00:00:00 GMT; path=/; HttpOnly
* Server cloudflare-nginx is not blacklisted
< Server: cloudflare-nginx
< CF-RAY: 210905e0082d03b8-SIN
<
<!DOCTYPE html>
<html itemscope itemtype="http://schema.org/QAPage">
... html content follows here ...
All the > lines are what is sent to the server as a request (as plain text over a socket connection) and the < lines are what is received back.
I have the following get:
#Get
public String represent(Variant variant) throws ResourceException
{
String text = "returntext";
text+="\r\n";
return text;
}
The response from invoking this service:
CFG - HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: text/plain;charset=UTF-8
Date: Mon, 29 Jul 2013 19:59:37 GMT
Server: Restlet-Framework/2.0.9
Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
Content-Length: 118
Connection: keep-alive
How do I change the connection header value to close ?
I think this maybe a restlet bug.
Whether the server closes the connection or not, depends on whether the client request asks for the connection to close or not.
Here is a sample Server code:
import org.restlet.data.Form;
import org.restlet.data.MediaType;
import org.restlet.data.Parameter;
import org.restlet.resource.Get;
import org.restlet.resource.ServerResource;
import org.restlet.util.Series;
public class TestRestlet extends ServerResource {
#Get
public String getImpl(){
return "Sample Response Text\r\n";
}
}
And here is what i got on linux commmand line (using only telnet):
[Please note that the last line in request-header in each request is followed by 2 newlines] [To avoid any confusion, some of the requests do not contain request-body.]
[root#mylinuxserver]# telnet 172.16.101.34 6060
Trying 172.16.101.34...
Connected to win7comp01 (172.16.101.34).
Escape character is '^]'.
GET /TestRestlet HTTP/1.1
Host: 172.16.101.34:6060
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=C2E77F4D0437E525A0FC66498EF09E8B; Path=/hotelSoft
Date: Wed, 31 Jul 2013 08:25:44 GMT
Accept-Ranges: bytes
Server: Restlet-Framework/2.0.15
Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
Content-Type: application/json;charset=UTF-8
Content-Length: 22
Sample Response Text
GET /TestRestlet HTTP/1.1
Host: 172.16.101.34:6060
Connection: Keep-Alive
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=1873DE26443F5DF62379B895AEA0F004; Path=/hotelSoft
Date: Wed, 31 Jul 2013 08:25:48 GMT
Accept-Ranges: bytes
Server: Restlet-Framework/2.0.15
Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
Content-Type: application/json;charset=UTF-8
Content-Length: 22
Sample Response Text
GET /TestRestlet HTTP/1.1
Host: 172.16.101.34:6060
Connection: close
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=43EC7C9AACC6C0CEF6FAC8F608B1D79C; Path=/hotelSoft
Date: Wed, 31 Jul 2013 08:25:57 GMT
Accept-Ranges: bytes
Server: Restlet-Framework/2.0.15
Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
Content-Type: application/json;charset=UTF-8
Content-Length: 22
Connection: close
Sample Response Text
Connection closed by foreign host.
[root#mylinuxserver]# telnet 172.16.101.34 6060
Trying 172.16.101.34...
Connected to win7comp01 (172.16.101.34).
Escape character is '^]'.
GET /TestRestlet HTTP/1.0
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=2C879A91F2501DD9D3B39EF50C3F46CA; Path=/hotelSoft
Date: Wed, 31 Jul 2013 08:26:09 GMT
Accept-Ranges: bytes
Server: Restlet-Framework/2.0.15
Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
Content-Type: application/json;charset=UTF-8
Content-Length: 22
Connection: close
Sample Response Text
Connection closed by foreign host.
[root#mylinuxserver]# telnet 172.16.101.34 6060
Trying 172.16.101.34...
Connected to win7comp01 (172.16.101.34).
Escape character is '^]'.
GET /TestRestlet
Sample Response Text
Connection closed by foreign host.
[root#mylinuxserver]#
In the above examples, several types of HTTP connections are made.
The response to the 1st request:
GET /TestRestlet HTTP/1.1
Host: 172.16.101.34:6060
[Note: the line Host: 172.16.101.34:6060 is followed by 2 \r\n: \r\n\r\n]
is:
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=C2E77F4D0437E525A0FC66498EF09E8B; Path=/hotelSoft
Date: Wed, 31 Jul 2013 08:25:44 GMT
Accept-Ranges: bytes
Server: Restlet-Framework/2.0.15
Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
Content-Type: application/json;charset=UTF-8
Content-Length: 22
Sample Response Text
The connection is not closed yet, and we send another request:
GET /TestRestlet HTTP/1.1
Host: 172.16.101.34:6060
Connection: Keep-Alive
That gets the response:
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=1873DE26443F5DF62379B895AEA0F004; Path=/hotelSoft
Date: Wed, 31 Jul 2013 08:25:48 GMT
Accept-Ranges: bytes
Server: Restlet-Framework/2.0.15
Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
Content-Type: application/json;charset=UTF-8
Content-Length: 22
Still the connection is not closed.
However on the 3rd request:
GET /TestRestlet HTTP/1.1
Host: 172.16.101.34:6060
Connection: close
The connection is closed, because the request contains Connection: close header.
You can see the telnet exits after displaying a message: Connection closed by foreign host.
There are 2 more sample request-response in the above given examples:
1.An HTTP 1.0 request:
GET /TestRestlet HTTP/1.0
With response:
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=2C879A91F2501DD9D3B39EF50C3F46CA; Path=/hotelSoft
Date: Wed, 31 Jul 2013 08:26:09 GMT
Accept-Ranges: bytes
Server: Restlet-Framework/2.0.15
Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
Content-Type: application/json;charset=UTF-8
Content-Length: 22
Connection: close
Sample Response Text
And the telnet exits after displaying: Connection closed by foreign host.
2.A request without HTTP version mentioned:
GET /TestRestlet
And response is: (Without headers)
Sample Response Text
And the telnet exits with a message: Connection closed by foreign host.
Conclusion:
Whatever is your client / client-program , make it send an HTTP-1.0 request , or a HTTP-1.1 request with Connection: close header.
In Java, you achieve this by:
import java.net.HttpURLConnection;
import java.net.URL;
.
.
.
HttpURLConnection httpURLConnection = (HttpURLConnection) new URL("http://....").openConnection();
httpURLConnection.setRequestProperty("Connection","close");
// rest of the code here....
Also check if a statement like this:
httpURLConnection.disconnect();
can help you disconnect the connection.