I noticed my home router has some configuration field "TR-069 CLIENT CONFIGURATION" and some obscure address that I noticed gets resolved quite often each day. (Yes obviously to config the router remotely.. or something) But I want to see what is being sent. So wrote a very simple "web server" in Java to read in HTTP requests (the field in the router was with a normal http:// address) and print them out. (i set that field to point to my computer where the little server is running)
And im getting these:
Host: 192.168.1.2
User-Agent: Allegro-Software-WebClient/4.07
Accept: */*
Content-Type: text/xml; charset=utf-8
Content-Length: 2767
SOAPAction:
Was kind of hoping SOAPAction: wouldnt be empty but what does this mean, is it some deprecated feature of the router that just happens to keep going? (its a d-link ADSL Router)
There would be multiple soap envelopes in HTTP Request.
TR-069 spec says
When there is more than one envelope
in a single HTTP Request, the
SOAPAction header in the HTTP Request
MUST have no value (with no quotes),
indicating that this header provides
no information as to the intent of the
message. That is, it should appear as
follows:
SOAPAction:
Related
My team and I have a Tomcat server running a Restfull webservice, implemented using RestEasy:
#POST
#GZIP
#Path("/capture")
#Consumes(MediaType.APPLICATION_JSON)
Response RecieveData(#GZIP RecievingData recievingData);
We need to make compressed post to this service. The problem is we are not finding an implementation that works.
We tried using interceptors:
https://hc.apache.org/httpcomponents-client-4.2.x/httpclient/examples/org/apache/http/examples/client/ClientGZipContentCompression.java. But we were unable to capture the POST request Body and compress it.
We tried using the RestEasy client but it doesn´t seems to be compreesing the body of the Post Request: www.posttestserver.com/data/2016/01/06/15.33.391016591335
Finally we tried a customized class: https://gist.github.com/takumakei/913067. But we got a 400 error on the request:
HTTP/1.1 400 Bad Request [Content-Encoding: gzip, Content-Type:
text/html; charset=UTF-8, Date: Thu, 07 Jan 2016 10:07:05 GMT, Server:
Apache-Coyote/1.1, Content-Length: 66, Connection: keep-alive]
We are out of ideas and this supose to be a simple function for an HTTP Client. Any ideas?
OBS: Here is the RestEasy Proxy:
#POST
#GZIP
#Consumes(MediaType.APPLICATION_JSON)
public Response saveData(#GZIP RecievingData customer);
EDIT: Got some changes in the Firewall and the 3rd method changed to an error 400.
If using Tomcat why not add a RequestFilter that will pre-process received requests that contain header Content-Encoding: gzip and decompress it before the rest of the filter chain handles it?
EDIT:
I'm guessing your third option may actually have worked (snoop the network to verify), the issue was you got 403 - Forbidden response from the server. That's a problem with authorization not with the URL, request encoding, or anything else. The GZIP might actually be working for you right now.
EDIT:
Your latest output for HTTP response code 400 - Bad Request shows Content-Type: text/html. The Controller is expecting Content-Type: application/json, so the client did not set the ContentType as required by the Controller. Recheck your usage and config of the client code.
In the end I used the Resteasy framework for server and client to implement the GZIP compression.
Server side:
https://docs.jboss.org/resteasy/docs/2.3.0.GA/userguide/html/gzip.html
Client Side:
https://docs.jboss.org/resteasy/docs/2.2.1.GA/userguide/html/RESTEasy_Client_Framework.html
That worked for me.
I tried to call web service from my java project(client). Then I got a exception
UnsupportedMediaException: Unsupported Content-Type: text/html Supported ones are: [text/xml]
After studying so many answers in net, I came to know that my web service expects text/xml, but my client is not able to send that. How could I check what request my client is sending and how to convert that thing into text/xml so that my web service understands.
You need to fix your java application to use text/xml as http header.
Java supports the mechanism so you can edit http header.
And to know what http request your client is sending, you can use wireshark or httpdebugger like fiddler.
In below code sample am getting the http method get is used as reQuest now want to know what are all the http methods my tomcat server support.Please help to find this.
GET / HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.6 (X11; I; Linux 2.2.6-15apmac ppc)
Host: zink.demon.co.uk:1126
Accept: image/gif, */*
There is no way to know this unless you ask the server which methods it supports.
Usually this is done with the OPTIONS HTTP method, but not all web servers support it. Also, it applies to a specific URL, not the whole server.
I've replaced the Tomcat by Jetty. Now I have 400 http error code for requests sent by a third party system. As I see, the difference with my tests sent by curl and a web-browser is the url in the http verb:
POST http://10.15.1.9:49302 HTTP/1.0
Host: 10.15.1.9
Content-Type: text/xml
Content-Length: 71065
User-Agent: hpost/0.1
Pragma: no-cache
Accept: */*
this request doesn't work, but post with relative URL such as POST / HTTP/1.0 works fine. Who is wrong? I cannot change the third party system, so, is it possible to make jetty accept such requests?
I've tried Jetty v6.1.26, v7.6.4 and v8.1.4 - works the same.
Ok, I think the reason is missing trailing slash after the url, the POST http://10.15.1.9:49302/ HTTP/1.0 works fine.
Does any body know if it is jetty problem or the client sends malformed url?
While the HTTP spec RFC-2616 says that the server must accept absoluteuri's for the request line, this is generally only used for proxy requests.
To Jetty, the request line POST http://10.15.1.9:49302 HTTP/1.0 is viewed as a HTTP/1.0 request, and fall into the rules of RFC-1945 for Request Line URIs that states absoluteuri's are always Proxy requests.
I've reported the issue, it is fixed now.
Worldpay (The payment processor from RBS) sends a HTTP Post to my website once a payment is accepted. Problem is - the Post isnt getting through and my server responds with one of the following 3 HTTP error's:
HTTP 408 (Timeout)
HTTP 405 (Not allowed)
Invalid status line >NULL<
Now when i Post something to the url from my test php script this works fine which leads me to believe the issue could be with the fact that the Post from them is created by Java:
POST /worldpay_success.html HTTP/1.0
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Host: www.mysite.com
Content-Length: 116
User-Agent: WJHRO/1.0 (WorldPay Java HTTP Request Object)
authAmountString=%26%23163%3B1.99&_SP.charEnc=UTF-8&desc=Test.....etc
Does anyone have any experience with this? After speaking to Worldpay they say my server is responding with a 408 Timeout after 0.1 seconds so it doesnt seem to be properly timeing out... Any help apreciated
Paul
Check 405 Method Not Allowed and Request Timeout. It shouldn't matter if the POST request is created from Java.