GET / HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: localhost:1255
Origin: http://testt:8080
Sec-WebSocket-Protocol: json
Pragma: no-cache
Cache-Control: no-cache
Sec-WebSocket-Key: sGGDklOmMNFmY2AniKkkGw==
Sec-WebSocket-Version: 13
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits, x-webkit-deflate-frame
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.103 Safari/537.36
this is what I've get during the handshake of websocket, but how could I get from here the cookie id?, I've thinked to pass the cookie after the handshake is done, but will that be correct?
where are the cookies hidden?
its connecting to my java socket, what class I can use in this case to get the cookie? or it would be better if I get it from the string above...
The string above does not contain any cookie. The browser sends cookies using a "Cookie" HTTP header, which is not in that request.
If you want the browser to send the webpage cookie, you have to put the WebSocket server and the web server in the same domain, otherwise the cookie won't be send.
It is technically possible to return cookies in the negotiation HTTP response (in a "Set-Cookie" HTTP header), and it will be resend in the next connection.
Related
i've sending the "same" request (a simple get-request) to a server and with Postman all works fine and with RestEasyClient it doesn't (401 Unauthorized)...
I looked on both requests by fiddler and saw some differences which might be the cause of the problem (i actually don't know) but at least in my opinion it makes no sense to send these parameters... but i have no idea where to turn it off, it seems to be a default behavior from RESTEasyClient.
Here the postman request:
GET https://xxxx/ping HTTP/1.1
Authorization: Bearer 7e6e4255-0d94-3d29-8527-fb5c8ff8e23b
cache-control: no-cache
Postman-Token: 7d54d38f-ca13-4fb0-8d14-18153f9b2f93
User-Agent: PostmanRuntime/7.3.0
Accept: */*
Host: xxxx
accept-encoding: gzip, deflate
Connection: close
Here the RESTEasyClient-Request:
GET https://tapi002-vpn-api.e-bk.m086/t1/msc-grawe/v1/ping HTTP/1.1
Authorization: Bearer 7e6e4255-0d94-3d29-8527-fb5c8ff8e23b
Host: xxxx
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.2 (Java/1.8.0_144)
Cookie: ROUTEID=.2
My questions are:
Why sends RESTEasyClient Connection: Keep-Alive? Wouldn't it be better to send connection close, because there is no session?!
Why does RESTEasyClient send a Cookie? I don't want and need any cookies...
And by the way: What's the postman token?!
Update:
The Cookie: ROUTEID=.2 causes the error... so the important question is how to remove the Cookie from the RESTEasyClient request header.
Update 2:
The server requested to set the cookie in the token-response... strange... i will try to remove the cookie...
Set-Cookie: ROUTEID=.1; path=/;Secure;HttpOnly; max-age=1200
Why sends RESTEasyClient Connection: Keep-Alive? Wouldn't it be better to send connection close, because there is no session?!
As for Keep-Alive: Because RestEasy uses HTTP/1.1 with connection reuse by default. That doesn't mean a session
Thanks to jokster for this answer.
Why does RESTEasyClient send a Cookie? I don't want and need any cookies...
RESTEasyClient does not send any cookies by default! In this case: Because the server requested the cookie in a request before...
And by the way: What's the postman token?!
Have a look at: What is the postman-token in generated code from Postman?
I'm trying to run a GWT project into DevMode, After running google compilation and lanching the devMode i'm getting a url, so when running into mozila, i'm getting the 503 error.
my console is displaying the following :
[ERROR] 503 - GET /travelApp?gwt.codesvr=127.0.0.1:49822 (127.0.0.1) 1296 bytes
Request headers
Host: localhost:8888
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Response headers
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 1296
i don't understand the problem, can you help me with that ?
What you see is the response from the webserver. The Error-Code is 503 - Service Unavailable (https://en.wikipedia.org/wiki/List_of_HTTP_status_codes).
Most likey, your application failed to start.
Do you have any logs? There might be any usefull stacktraces.
Do you use the build-in Jetty? I found out, that it's sometimes hard to get log entries from it. Maybe you can try to deploy the application to tomcat to get a more helpful errorlog.
I'm trying to enable http response compression on Spring boot web application.
It works for some user-agents, and for some reason doesn't for others (specific cases below).
My basic question is:
Why http response compression (gzip) in Spring Boot works only for some User-Agent headers and where it is configured.
Spring boot reference doesn't say anything about it.
I prepared simple web application with enabled compression: sample spring-boot-compression app
There are integration tests that verify that gzip encoding works for some cases only.
I configured spring boot with:
server:
tomcat:
compression: on
compressable-mime-types: text/html,text/css,application/javascript,application/json,application/font-sfnt,application/font-woff,application/font-woff2
When I try to do some requests with curl:
$ curl -i -H "Accept-Encoding: gzip,deflate" http://localhost:8080
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Content-Encoding: gzip
Vary: Accept-Encoding
I see that Content-Encoding: gzip header is set.
When I setUser-Agent to AppleWebKit (or some other browsers like IE) it does not compress:
$ curl -i -H "Accept-Encoding: gzip,deflate" -H "User-Agent: AppleWebKit" http://localhost:8080
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Vary: Accept-Encoding
I repeated my tests with some other browsers and User-Agent header modification and received some strange results.
Here some of working (response is compressed) User-Agent headers:
- Mozilla/5.0
- Mozilla/5.0 (Windows NT 6.1; WOW64) Chrome/46.0.2490.80 Safari/537.36
- Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Firefox/34.0
- SomeUnknownBrowser
Some of not working User-Agent headers:
- AppleWebKit
- Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36
- Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
- Gecko/20100101
I also tried to use compression with GzipFilter and it behaves exactly the same. Also tried embedded Jetty instead of Tomcat - same result.
Maybe I'm just missing something.
You're probably using some sort of antivirus (maybe ESET). Try turning off HTTP protection.
With Eset you can try something like: Advanced -> Internet and email -> Web Access Protection - turn off.
This worked for me with Spring 1.4
server.compression.enabled: true
server.compression.mime-types: application/json,application/xml,text/html,text/xml,text/plain,text/css,application/javascript
I am trying to write a simple java server that receives HTTP GET requests from web browser and sends back some data. All the communication is done via sockets.
I am able to process the requests and now I am trying to implement a simple authentication with BASIC AUTH so some requests will be handled only if correct credentials are provided in the request header. For sake of simplicity, I am using only http protocol (not https). I am not sure how to access the header and read the credentials on my server, though:
The server runs on localhost, port 9000 and this is the sample URL that I am trying to process:
http://user:password#localhost:9000/files/text?tid=file3
I open the socket and read everything:
InputStream input = clientSocket.getInputStream();
// Reading line by line with a BufferedReader
java.io.BufferedReader in = new java.io.BufferedReader(new String line;
while (!(line = in.readLine()).equals("")) {
System.out.println(line);
}
This is what I get:
GET /files/text?tid=file3 HTTP/1.1
Host: localhost:9000
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/41.0.2272.76 Chrome/41.0.2272.76 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
There is no trace of the auth credentials I put in the URL so I am not sure how to parse the request. Could you tell me what am I missing here?
I know that this example is very simple and there are more clever ways to implement this but I am curious how to access these credentials in this simple model case.
Use a client like curl:
$ curl -v -u user:password "http://localhost:9000/files/text?tid=file3"
Since HTTP is stateless, sending the Authentication header is enough. That's what curl does. It is not necessary to wait for the server to return a 401.
In my project I use Apache's HttpComponents to connect to a server. The following code creates the HttpClient.
HttpParams params = new BasicHttpParams();
params.setParameter("http.language.Accept-Language", "de-de,de;q=0.8,en-us;q=0.5,en;q=0.3");
HttpProtocolParams.setUserAgent(params, "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1003.1 Safari/535.19 Awesomium/1.7.1");
DefaultHttpClient client = new DefaultHttpClient(params);
But when I execute a request, the Accept-Language field is not sent. Just the following:
2013/04/06 20:52:07:129 MESZ [DEBUG] headers - >> GET /ws/search.json?text=&levelmin=0&levelmax=80&offset=1 HTTP/1.1
2013/04/06 20:52:07:129 MESZ [DEBUG] headers - >> Host: tradingpost-live.ncplatform.net
2013/04/06 20:52:07:129 MESZ [DEBUG] headers - >> Connection: Keep-Alive
2013/04/06 20:52:07:129 MESZ [DEBUG] headers - >> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1003.1 Safari/535.19 Awesomium/1.7.1
2013/04/06 20:52:07:129 MESZ [DEBUG] headers - >> Cookie: s=abcdefg
Is it a bug or did I do something wrong? I just want to have a "global" accept-language field (for all requests I send from one client).
Any help would be welcome
I was not able to fix that problem, but here's a workaround for anyone issuing the same problem:
Create a central method like
void prepareHttpRequest(HttpRequest request){
request.addHeader("Accept-Language", "de-de,de;q=0.8,en-us;q=0.5,en;q=0.3");
}
You have to do that for every POST-or GET-request you do. I know that it's not very elegant, but my only solution,