I am trying to read and parse an rss feed from a 2 jetty servers (Eclipse - Google Plugin): one with App engine SDK enabled and one without it.
1. When i test on the jetty run with app engine enabled it works fine
2. When i use the same code on a jetty server without app engine enabled i get the following message (because the received text is empty):
javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,1]
Message: Premature end of file.
I searched the code for a premature reading of the input stream (I use new URL(host) and url.openStream() to read the input), but the code is OK (if it wasn't it wouldn't probably work in the first case).
I used tcpdump (-s 1024 -l -A dst host.com -i wlan0) to examine the headers:
first case:
GET /rss/... HTTP/1.1
Host: www.host.com
Connection: Keep-Alive
Cookie: environment=a%3A2%3A%7Bs%3A4%3A%22skin%22%3Bs%3A7%3A%22default%22%3Bs%3A4%3A%22lang%22%3Bs%3A5%3A%22ro_RO%22%3B%7D; isPC=1
Cookie2: $Version=1
second case:
GET /rss/... HTTP/1.1
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Java/1.6.0_39
Host: www.host.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, /; q=.2
Connection: keep-alive
Could those headers be the issue ? Is there a way to set the exact same headers ? And would it solve the problem ?
I seams that the problem was the User-Agent header, which determined some servers to send empty content for some values (like Jav/1.6.0_39 in my case). I set the User-Agent to empty string and now the response is ok.
Related
I'm building a Java websocket server using Tomcat. On my dev build, it works perfectly. However when I deploy it to production, the server is automatically appending "close" to the connection response header, immediately closing the socket (which never seems to connect to the server in the first place).
Here's some context for the production environment:
Tomcat 7, Java 8 on RHEL
Communications are encrypted by SSL, websocket uses wss
The server is behind an institutional firewall (but I expect that the encryption should make this a non-issue)
My local dev environment is not an exact clone (as it's used for multiple projects). It's running Tomcat 8, but I believe Tomcat 7 should feature comparable websocket support.
Here's the request/response (as captured by Chrome dev tools) when the websocket is sent to the production server:
General:
Request URL: wss://example.com/WSServer
Request Method: GET
Status Code: 101 Switching Protocols
Response:
HTTP/1.1 101 Switching Protocols
Date: Thu, 10 May 2018 17:04:39 GMT
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Upgrade: websocket
Connection: upgrade, close
Sec-WebSocket-Accept: JFNyciPc/Cza8PFaXWVct6f21qw=
Sec-WebSocket-Extensions: permessage-deflate;client_max_window_bits=15
Content-Length: 0
Content-Type: text/plain; charset=UTF-8
Request:
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cache-Control: no-cache
Connection: Upgrade
Cookie: *redacted*
Host: example.com
Origin: https://example.com
Pragma: no-cache
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Sec-WebSocket-Key: OvMcwMxIYqBLrx9ijlFK/w==
Sec-WebSocket-Version: 13
Upgrade: websocket
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36`
As far as I can tell, the most revealing part of this is Connection: upgrade, close, which explains the client-side behavior below.
Here's a snippet of the client-side Javascript:
var socket = new WebSocket((window.location.protocol==="http:"?"ws:":"wss:") + "//" + window.location.host + "/WSServer");
socket.onopen = function wsOpen() {
socket.send("Hello!"));
}
socket.onclose = function wsClose(reason) {
log(JSON.stringify(reason)); //debug
}
socket.onopen gets called first. Executed normally, this doesn't produce any console message, but if I delay its execution with a breakpoint I get an error message: "Websocket is already in CLOSED or CLOSING state."
socket.onclose gets called immediately after. The reason code is 1006 with no explanation.
I've also put some debug logging in the ServerEndpointConfig.Configurator.modifyHandshake method, but it never reaches that point, nor does it reach the #OnOpen-annotated method.
Any idea what's causing the connection to fail? Again, the server and client code works in dev, so I'm confident that it's not a code issue. Is it a Tomcat configuration issue (as far as I can tell, there's nothing unusual about the way it's setup). Is there something obvious I'm missing?
Thanks in advance for any help!
HTTP/1.1 enables keep-alive connections by default.
A request such as:
GET / HTTP/1.1
Host: example.com
Connection: close
tells the server to disable keep-alive on the connection (the opposite of the HTTP/1.1 default)
Upgrade is a hop-by-hop header, just like Connection, and Upgrade is only valid if listed in Connection, e.g. Connection: Upgrade
When a client makes an HTTP/1.1 request containing Upgrade, the server receiving the request is not required to upgrade, and can instead simply respond with an HTTP/1.1 response.
Connection: upgrade, close requests that the server upgrade to (one of) the protocol(s) in the Upgrade header, or else to respond with HTTP/1.1 and close the connection. If the server upgrades the protocol, then the server uses the new protocol, and the close token in Connection is ignored, as the server is now using the upgraded protocol in the Upgrade response header immediately after the HTTP/1.1 101 Switching Protocols response.
I keep getting the following error in my Response data tab in jmeter:
org.apache.http.client.ClientProtocolException
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:909)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:481)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:298)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1105)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1094)
at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:429)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:257)
at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.http.ProtocolException: Transfer-encoding header already present
at org.apache.http.protocol.RequestContent.process(RequestContent.java:93)
at org.apache.http.protocol.ImmutableHttpProcessor.process(ImmutableHttpProcessor.java:109)
at org.apache.http.protocol.HttpRequestExecutor.preProcess(HttpRequestExecutor.java:176)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:518)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
... 9 more
My test script was created via the JMeter Proxy. The test is sending multipart data (a jpg image) to a REST API resource via a POST. The HTTP Header Manager auto created by the Recording Controller in JMeter has the following:
Transfer-Encoding : chunked
Accept : application/json
Accept-Encoding : gzip, deflate
Any idea why the Response is getting an error?
Request:
POST http://localhost:8080/email/v2/client/user/name/loadtest1#test.net/
POST data:
--oYtJU-XXTgMSkyaIrRBYNXw8AfMA2nMQSzJ20bJr--
Cookie Data:
JSESSIONID=b3bb843e-dafd-4cc5-8b0b-045c490736f8
Request Headers:
Connection: keep-alive
Transfer-Encoding: chunked
Accept: application/json
Accept-Encoding: gzip, deflate
Try removing from HTTP Header Manager the Transfer-Encoding header.
Can you show you Http Request in your Question ? and the Header Manager in it ?
What is the status of the following parameters of the http request which is failing:
Use multipart/form-data for HTTP POST
Browser-compatible headers
You don't have any HTTP Header Manager instances elsewhere in you test plan, do you? As if yes it may interfere as HTTP Header Manager's scope isn't limited to one sampler only when it is not added as a child.
Your post request details doesn't look like file upload request. Take a look into Upload and Download Scenarios with Apache JMeter guide to see whether you missed anything important.
Never run load generator and application under test on the same machine. Even when developing or debugging your test.
I wrote a JAX-WS client using classes generated from wsimport to invoke a webservice. To test my client locally, I wrote an implementation of the webservice and published it locally and called it. Everything worked as expected.
One thing I noticed is that my client connects to the endpoint and issues a GET followed by another connection with a GET against the endpoint looking for the wsdl, and finally issues the POST with my payload in the same connection.
Here is the tcpmon output (edited to protect the guilty):
GET /someWS HTTP/1.1
User-Agent: Java/1.7.0_03
Host: 127.0.0.1:9877
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
----------------------------------
GET /someWS?wsdl HTTP/1.1
User-Agent: Java/1.7.0_03
Host: 127.0.0.1:9877
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
POST /someWS HTTP/1.1
Accept: text/xml, multipart/related
Content-Type: text/xml; charset=utf-8
SOAPAction: "document/http://someUrl"
User-Agent: JAX-WS RI 2.2.4-b01
Host: 127.0.0.1:9877
Connection: keep-alive
Content-Length: 610
<Valid Soap message here/>
Is this standard behaviour or I have messed something up? I am using JAX-WS RI 2.2. This works fine locally, but a certain production WS is quite unhappy with the initial GET request and throws a 500 and I was hoping that I could suppress the GET requests and just skip to the POST.
The client is not caching the wsdl file locally and hence you will see a GET request before every POST. The GET is for getting the wsdl file and the POST is for the actual web service request. Ask the client to cache the wsdl locally and refer to it.
I am trying to upload a file with certain METADATA to an azure blob container.
When I do it with the .net SDK it simple sends one put and all metadata as it should be.
However, if I try with Java it sends 3 puts and the metadata won't be reflected until I issue a cBlockBlob.uploadProperties() command, and until the 3rd put.
Why is it going through 3 puts? is it an issue in the JAVA sdk?
This is the 1st put
*PUT /mycontainer/0721ef8f-8d70-4b91-9d1f-04757363f903.xml?blockid=AAAAAEm%2FC%2FE%3D& comp=block&sr=c&timeout=4&si=WriteOnly& sig=eUe%2Fe7kcFcmiIzOVNgqbXd%2BjlIN3ZQd8fkQq3IsHQVQ%3D HTTP/1.1
x-ms-version: 2011-08-18
User-Agent: WA-Storage/Client v0.1.1
Content-Type:
Host: certainhost.blob.core.windows.net
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 4613*
This is the 2nd put
*PUT /mycontainer/0721ef8f-8d70-4b91-9d1f-04757363f903.xml?comp=blocklist&sr=c&timeout=4&si=WriteOnly&sig=eUe%2Fe7kcFcmiIzOVNgqbXd%2BjlIN3ZQd8fkQq3IsHQVQ%3D HTTP/1.1
x-ms-version: 2011-08-18
User-Agent: WA-Storage/Client v0.1.1
Content-Type:
Content-MD5: hYRJFeM5RFH29bPj3oxhwA==
Host: certainhost.blob.core.windows.net
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 100*
<?xml version='1.0' encoding='UTF-8'?><BlockList><Uncommitted>AAAAAEm/C/E=</Uncommitted></BlockList>
This is the 3rd put (the one that shows required metadata)
*PUT /mycontainer/0721ef8f-8d70-4b91-9d1f-04757363f903.xml?comp=properties&sr=c&timeout=4&si=WriteOnly&sig=eUe%2Fe7kcFcmiIzOVNgqbXd%2BjlIN3ZQd8fkQq3IsHQVQ%3D HTTP/1.1
x-ms-version: 2011-08-18
User-Agent: WA-Storage/Client v0.1.1
Content-Type:
x-ms-blob-content-encoding: utf-8
x-ms-meta-x-ms-meta-versionCFDI: 3.2
Host: certainhost.blob.core.windows.net
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 0*
and this is the only put in .net SDK
*PUT /mycontainer/0721ef8f-8d70-4b91-9d1f-04757363f903.xml?comp=properties&sr=c&timeout=4&si=WriteOnly&sig=eUe%2Fe7kcFcmiIzOVNgqbXd%2BjlIN3ZQd8fkQq3IsHQVQ%3D HTTP/1.1
x-ms-version: 2009-09-19
User-Agent: WA-Storage/6.0.6002.18312
x-ms-blob-type: BlockBlob
x-ms-meta-versionCFDI: 3.2
Host: certainhost.blob.core.windows.net
Content-Length: 6841
Connection: Keep-Alive*
Something else, what does this mean?
<?xml version='1.0' encoding='UTF-8'?><BlockList><Uncommitted>AAAAAEm//E=</Uncommitted></BlockList>
It is sent in the second put, .net won't show it.
I believe what's happening is that JAVA SDK is splitting your file into blocks and uploading those blocks. The first PUT request a "PUT Block" request and the second one is the "Commit Block List" request and the 3rd one is the "Set Metadata" request. Based on the REST API documentation, you can set a blob's metadata during "Commit Block List" operation as well (http://msdn.microsoft.com/en-us/library/windowsazure/dd179467.aspx). It does seem odd that .Net SDK uploads this file in just one request while Java SDK splits the file in blocks and upload it. I wouldn't be surprised if this is how it is implemented in Java SDK. What's the size of the file which you're trying to upload?
Regarding your 2nd question, that's the payload for "Commit Block List" operation.
I'm watching CXF service traffic using DonsProxy, and the CXF client sends an HTTP header "SoapCompressed":
HttpHeadSubscriber starting...
Sender is CLIENT at 127.0.0.1:2680
Packet ID:0-1
POST /yada/yada HTTP/1.1
Content-Type: text/xml; charset=UTF-8
SoapCompressed: true
Accept-Encoding: gzip,gzip;q=1.0, identity; q=0.5, *;q=0
SOAPAction: ""
Accept: */*
User-Agent: Apache CXF 2.2
Cache-Control: no-cache
Pragma: no-cache
Host: localhost:9090
Connection: keep-alive
Transfer-Encoding: chunked
I'd like to turn SoapCompressed off in my dev environment so that I can see the SOAP on the wire. I've searched Google and grepped the CXF source code, but don't see anything in the docs or code that reference this. Any idea how to make the client send "SoapCompressed: off" instead, without routing it through Apache HTTPD or the like? Is there a way to configure it at the CXF client, in other words?
A grep of the CXF codebase doesn't yield "SoapCompressed" at all. I really don't think it's CXF that is sending that. The Accept-Encoding thing is also suspect as that is only sent if you enable the GZIP interceptors. Is it possible that the proxy thing you are using is adding it?
The client for org.apache.cxf.jaxrs.client.AbstractClient has points where you set the headers in a key-value map (Map). "SoapCompressed", "false".