I have cloned the following webSocket project https://github.com/thegeekyasian/WebSocket-SpringBoot and the server is up and running. And postman client was able to connect to the server successfully. But when I rename the packages of this project and I try to connect to the server using postman client I have the following error. Could you please help?
Could not connect to ws://localhost:8080/webSocket
09:38:35
Error: Unexpected server response: 404
Handshake Details
Request URL: http://localhost:8080/webSocket
Request Method: GET
Status Code: 404
Request Headers
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: GmRXEBdLLrcJuIQH59nkuA==
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Host: localhost:8080
Response Headers
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Date: Wed, 11 Jan 2023 17:38:35 GMT
I tried to connect using ws://localhost:8080/webSocket
Related
We are trying to consume the Informatica 10.1.0 REST API but it is failing at login itself with 404, and there is no error message from the server. response is blank
Ours is NOT cloud. It is an ON PREM installation.
The manual URL is
http://<SERVER>:<PORT>/tdm/
So my login REST CALL is:
POST http://<SERVER>:<PORT>/ma/api/v2/user/login HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/json
Accept: application/json
Content-Length: 60
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.5 (Java/12.0.1)
{
"#type": "login",
"username": "XXXX",
"password": "YYYY"}
Response is:
HTTP/1.1 404 Not Found
Content-Length: 0
Date: Fri, 04 Dec 2020 07:00:49 GMT
Server: Informatica
Nothing else. Are we missing anythig?
I have a problem with tomcat included with spring boot. i want to disable the chunked encoding or even using the HTTP 1.0 version as it doesn't use it. i don't have a java class for that i just want to change the properties.
below the part of the HTTP response header that i received with the chunked encoding
HTTP/1.1 200
Date: Thu, 26 Sep 2019 15:46:57 GMT
Content-Type: application/xml;charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
We have created a JAX-WS webservice, this service is being invoked by multiple clients. Some clients have configured timeout for API response. Even after sending success response, some client are stating that request is being timed out.
So is there any way to track, at what time a particular request hits the server and what time server responded back ?
I've enable http traces in weblogic server by using below properties
-Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true
-Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true
And request and response are appearing like below, where timestamp is missing
---[HTTP request - ]---
Accept: text/xml, multipart/related
Content-Type: text/xml; charset=utf-8
SOAPAction: ""
---[HTTP response 200]---
null: HTTP/1.1 200 OK
Content-Length: 521
Content-Type: text/xml;charset=UTF-8
Weblogic Version is - 12.2.1
A broken HTTP client sent some requests to our Jetty-based HTTP server with a newline in the URL. Jetty sees this as an HTTP/0.9 request, truncates the URL at the newline, ignores the request headers, and sends back a response with no headers or status line.
I believe this is mostly correct according to spec, although Jetty doesn't require CRLF and will happily do this for requests other than GET. But newer specs note that HTTP/0.9 requests mainly indicate confused clients. In our case, the client (and we) could have avoided some confused troubleshooting if an error message had been sent instead.
How can I get Jetty to return an error response to requests with a newline in the URL? I'm happy to use either Jetty-level configuration or webapp-level code.
First, support for HTTP/0.9 has been completely removed in Jetty 9.3+.
Lets see what the behavior is ...
Jetty Distribution 9.2.7.v20150116, running demo-base:
Normal HTTP/1.0 Request:
$ printf "GET / HTTP/1.0\r\n\r\n" | nc localhost 8080
HTTP/1.1 200 OK
Set-Cookie: visited=yes
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Accept-Ranges: bytes
Content-Type: text/html
Last-Modified: Sat, 17 Jan 2015 00:25:03 GMT
Content-Length: 2773
Server: Jetty(9.2.7.v20150116)
<html xmlns=\ "http://www.w3.org/1999/xhtml\" xml:lang=\"en\">
Got the headers there, looks like HTTP/1.0 response headers too.
Normal HTTP/1.1 Request:
$ printf "GET / HTTP/1.1\r\nHost: localhost\r\nConnection: close\r\n\r\n" | nc localhost 8080
HTTP/1.1 200 OK
Set-Cookie: visited=yes
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Accept-Ranges: bytes
Content-Type: text/html
Last-Modified: Sat, 17 Jan 2015 00:25:03 GMT
Content-Length: 2773
Connection: close
Server: Jetty(9.2.7.v20150116)
<html xmlns=\ "http://www.w3.org/1999/xhtml\" xml:lang=\"en\">
Looks normal as well.
Even includes the HTTP/1.1 specific headers.
Now lets try HTTP/1.0 with embedded CRLF:
$ printf "GET /\r\nHTTP/1.0\r\n\r\n" | nc localhost 8080
<html xmlns=\ "http://www.w3.org/1999/xhtml\" xml:lang=\"en\">
No response headers.
Why is this happening?
Well, there's no HTTP Version that Jetty can determine, so there's no valid set of headers it can respond with. So it responds with no headers. Which surprisingly is how HTTP spec prior to 1.0 behaved.
Now lets try Jetty Distribution 9.3.x, and the demo-base configuration with the same CRLF issue.
$ printf "GET /\r\nHTTP/1.0\r\n\r\n" | nc localhost 8080
HTTP/1.1 400 HTTP/0.9 not supported
Content-Length: 0
Connection: close
Server: Jetty(9.3.0-SNAPSHOT)
Now, in the modern era, with HTTP/2 just around the corner, this makes a lot more sense.
HttpServletRequest#getProtocol() will return an empty String for HTTP/0.9 requests in Jetty 8. Thus a simple filter can return a Bad Request response for such requests.
As the other answer indicates, HTTP/0.9 requests are no longer supported in recent versions of Jetty 9.
I am getting this Error is java.io.IOException: Server returned HTTP response code: 500 for URL: exception while invoking the web service url that i have.
I am calling a .NET based web service through a framework built in java and getting:
Headers returned from the server:
Content-Length:736
Content-Type:text/xml; charset=utf-8
Server:Microsoft-IIS/7.0
X-Powered-By:ASP.NET
Date:Thu, 12 May 2011 08:51:45 GMT
java.io.IOException: Server returned HTTP response code: 500 for URL: "http://hcd
cd-bt01.hcch.com/HCCExceptionLogService/service.svc?wsdl"
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLCon
nection.java:1170)
at com.splwg.mpl.senders.http.HTTPSender.sendResponse(HTTPSender.java:34
5)
at com.splwg.mpl.sending.NewSenderManager.sendResponse(NewSenderManager.
java:191)
at com.splwg.mpl.sending.SameThreadSendingManager.callSender(SameThreadS
endingManager.java:63)
at com.splwg.mpl.stagingtable.download.OutboundMessageSender.handleRouti
ngs(OutboundMessageSender.java:361)
at com.splwg.mpl.stagingtable.download.OutboundMessageSender.sendRespons
e(OutboundMessageSender.java:95)
at com.splwg.mpl.sending.NewSenderManager.sendResponse(NewSenderManager.
java:191)
at com.splwg.mpl.sending.SameThreadSendingManager.processDestination(Sam
eThreadSendingManager.java:293)
at com.splwg.mpl.sending.SameThreadSendingManager.sendResponse(SameThrea
dSendingManager.java:252)
at com.splwg.mpl.sending.SameThreadSendingManager.doSend(SameThreadSendi
ngManager.java:208)
at com.splwg.mpl.server.async.ExecSendRequestProcessor.ProcessRequest(Ex
ecSendRequestProcessor.java:61)
at com.splwg.mpl.server.async.RequestProcessingThreadAdapter.run(Request
ProcessingThreadAdapter.java:46)
at com.splwg.mpl.server.PooledThread.run(PooledThread.java:91)
at java.lang.Thread.run(Thread.java:595)
The wsdl url which i am invoking is http://hcdcdbt01.hcch.com/HCCExceptionLogService/service.svc?wsdl
I have used SOAP UI 3.6.1 tool for testing this wsdl which is giving me the right result.
Headers that i have used are:
Content-Type: text/xml;charset=UTF-8
SOAPAction: "http://tempuri.org/IExceptionLogService/LogException"
POST
Host:hcdcd-bt01.hcch.com
http://hcdcd-bt01.hcch.com/HCCExceptionLogService/service.svc
SOAP UI HEADERS:
POST http://hcdcd-bt01.hcch.com/HCCExceptionLogService/service.svc HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset=UTF-8
SOAPAction: "http://tempuri.org/IExceptionLogService/LogException"
User-Agent: Jakarta Commons-HttpClient/3.1
Host: hcdcd-bt01.hcch.com
Content-Length: 763
Can any body tell me what went wrong ?
It is a server error response, presumably on an internal service as the given address doesn't reside on the internet AFAIK.
You must get the server logs to establish what it does not like about your request.
Since the server sent the response code 500 - internal server error - I think you'll have to debug it on the server side, not the client side.
You should check the output of the server log.