I am receiving this POST request from a client:
HTTP method: POST
Host: 127.0.0.1:52400
Connection: keep-alive
Content-Length: 18
Pragma: no-cache
Cache-Control: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: null
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.122 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip,deflate
Accept-Language: da-DK,da;q=0.8,en-US;q=0.6,en;q=0.4,es;q=0.2
fname=foof&pw=bar
I have a small and very simple Java Webserver running, getting this request from InputStream.
From the BufferedReader I set data to a String, containing the request, like this:
for (String line; (line = in.readLine()) != null; ) {
if (line.isEmpty()) break;
header += line + "\n";
}
When I print header to the console, I get this:
POST / HTTP/1.1
Host: 127.0.0.1:52400
Connection: keep-alive
Content-Length: 18
Pragma: no-cache
Cache-Control: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: null
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.122 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip,deflate
Accept-Language: da-DK,da;q=0.8,en-US;q=0.6,en;q=0.4,es;q=0.2
The POST parameters are left out
I guess the problem occurs due to the blank line in the post-request.
How can I make sure the BufferedReader does read the request to the end, and not stopping at the blankline, all though stopping when the BufferedReader hits the end of the request.
Please ignore the lack of security in this example - I simply need to get the POST request into plain string representation for now.
Any help on this i appreciated, thanks!
Jesper.
The problem is because you have a break in your for loop. When you reach the blank line, it hits the break and exits the loop, not adding any of the lines after that. Instead, you should use this:
for (String line; (line = in.readLine()) != null; ) {
if (line.isEmpty()) continue;
header += line + "\n";
}
By using continue instead of break, the loop will simply proceed to the next iteration, and the rest of the lines can be added.
More information can be found here
Related
I am trying to build a REST web server where GET requests are non-blocking, even if it needs to make a slightly time consuming call.
#RestController
public class Endpoint {
static int callCount = 0;
#RequestMapping (value = "/endpoints", method = RequestMethod.GET)
public DeferredResult<Integer> someGetMethod() {
System.out.println("Mita: GET Called. Count#: " + callCount++);
DeferredResult<Integer> deferredResult = new DeferredResult<>();
new Thread( () -> {
deferredResult.setResult(getSomething());
}).start();
System.out.println("Mita: Thread started");
return deferredResult;
}
private int getSomething() {
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
return 100;
}
}
To test, I sent two GET requests from Restlet, to the same endpoint, in intervals of around 2 seconds. Yet, I see the following in DEBUG level logs of my spring application.
2017-08-26 01:16:38.231 DEBUG 1252 --- [nio-8080-exec-1] o.a.coyote.http11.Http11InputBuffer : Received [GET /endpoints/ HTTP/1.1
Host: localhost:8080
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36
Accept: */*
DNT: 1
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8,es;q=0.6,zh-CN;q=0.4,zh;q=0.2
]
...
...
2017-08-26 01:16:43.399 DEBUG 1252 --- [nio-8080-exec-2] o.a.coyote.http11.Http11InputBuffer : Received [GET /endpoints/ HTTP/1.1
Host: localhost:8080
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36
Accept: */*
DNT: 1
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8,es;q=0.6,zh-CN;q=0.4,zh;q=0.2
]
Notice, how the two requests came right after 5 seconds, the exact interval I have called sleep for (even though I had sent the request ~2 seconds after the first one). So, it seems like tomcat is sequentializing the incoming requests. How can I make tomcat not to sequentialize the requests? Or is it that I am missing something very obvious.
Using DeferredResult (or Servlet asynch mode that it uses) wont prevent the client (in this case Restlet) not to wait 5 seconds before it gets response from the first request.
To the client calling your Spring endpoint will look just as if the Spring endpoint was not using asynch mode at all. This means that Restlet or Tomcat can potentially wait till first request is finished before serving second request to your endpoint.
i have this ajax function that looks like so
$.ajax({
type: "POST",
url: "http://localhost:55556",
data: "lots and lots of pie",
cache: false,
success: function(result)
{
alert("sent");
},
failure: function()
{
alert('An Error has occured, please try again.');
}
});
and a server that looks like so
clientSocket = AcceptConnection();
inp = new BufferedReader(new InputStreamReader (clientSocket.getInputStream()));
String requestString = inp.readLine();
BufferedReader ed = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));
while(true){
String tmp = inp.readLine();
System.out.println(tmp);
}
now the odd thing is when i send my ajax my server gets by using system.out
Host: localhost:55556
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 20
Origin: null
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
the question is where is the data that i sent through, where is lots of pie?
The data should come after a blank line after the header lines, but I think the problem is that the data does not end with a newline character, and therefore, you cannot read it with the .readLine() method.
While looping through the header lines, you could look for the "Content-Length" line and get the length of the data. When you have reached the blank line, stop using .readLine(). Instead switch to reading one character at a time, reading the number of characters specified by the "Content-Length" header. I think you can find example code for this in this answer.
If you can, I suggest you use a library to help with this. I think the Apache HTTP Core library can help with this. See this answer.
i have a webpage with a webform. I's basically an input field and a selector, but there are a couple hidden fields. I need to send a POST request to this page (this is a search page basically). I've constructed the request as the following:
HttpClient httpClient = new DefaultHttpClient();
HttpConnectionParams.setConnectionTimeout(httpClient.getParams(), 10000);
HttpConnectionParams.setSoTimeout(httpClient.getParams(), 10000);
HttpPost httpPost = new HttpPost("http://www3.u-szeged.hu/kereses_terem.ivy");
httpPost.setHeader("Content-Type", "multipart/form-data");
httpPost.setHeader("name", "search-terem");
List<NameValuePair> nameValuePairs = new ArrayList<NameValuePair>();
nameValuePairs.add(new BasicNameValuePair("qsearch", "601"));
nameValuePairs.add(new BasicNameValuePair("medium-subtype", "meta-KOD"));
//and a lot of other parameters, please read on
httpPost.setEntity(new UrlEncodedFormEntity(nameValuePairs));
HttpResponse response = httpClient.execute(httpPost);
I've captured the sent request with Fiddler2, here is the raw request:
POST **************** HTTP/1.1
Content-Type: multipart/form-data
name: search-terem
Content-Length: 760
Host: ****************
Connection: Keep-Alive
User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)
qsearch=601&medium-subtype=meta-KOD&meta-KOD=&meta-CIM=&num=20&root-id=epulet&relation-types=child+vchild&medium-type=meta&object-types=etr_epulet&result-order=caption&result-order-direction=ASC&pageloader.preexecute=%09%2Fivy%2Fiem-shared%2Fsystem%2Fgems%2Fform-cye%2Fform-engine.xslt&request.formXML=%25webroot%25%2Fxml%2Fforms%2Fusz-search-terem.xml&request.formAPage=%09start&request.form-save-id=epulet&request.form-save-type=col&request.form-save-enabled=true&request.form-instance=2F58DD5D-BFCC-43A4-9B0C-0BC7BF887242&request.form-save-to-instance=false&request.form-redirect-to=kereses_terem.ivy&request.form-language=hu-HU&request.form-save-language=hu-HU&request.instance-id=2F58DD5D-BFCC-43A4-9B0C-0BC7BF887242&request.formPage=--finish--&cmd=submit
If the send the form in the browser, this is the sent request:
POST http://www3.u-szeged.hu/object.epulet.ivy HTTP/1.1
Host: www3.u-szeged.hu
Connection: keep-alive
Content-Length: 3033
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://www3.u-szeged.hu
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryuiCLY3ISz0tLmrvg
Referer: http://www3.u-szeged.hu/object.epulet.ivy
Accept-Encoding: gzip,deflate,sdch
Accept-Language: hu-HU,hu;q=0.8,en-US;q=0.6,en;q=0.4
Cookie: ivy:state-id:persistent=c9581db3-7a49-4e39-9130-3635b491385b; ivy:state-id:session=271fb66f-9579-4f13-a5b6-56c81dea4206
------WebKitFormBoundaryuiCLY3ISz0tLmrvg
Content-Disposition: form-data; name="meta-KOD"
------WebKitFormBoundaryuiCLY3ISz0tLmrvg
Content-Disposition: form-data; name="meta-CIM"
------WebKitFormBoundaryuiCLY3ISz0tLmrvg
Content-Disposition: form-data; name="num"
20
//and so on
This is obviously not the same, therefore the server responds with 0 results. How can i send a POST request like this? Thanks!
I want to replicate a working POST request in Java. For testing purpose, lets take message like: 'äöõüäöõüäöõüäöõü'
Working POST request (with encoded message of 'äöõüäöõüäöõüäöõü'):
Header
POST http://www.mysite.com/newreply.php?do=postreply&t=477352 HTTP/1.1
Host: www.warriorforum.com
Connection: keep-alive
Content-Length: 403
Origin: http://www.mysite.com
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko)Chrome/14.0.835.202 Safari/535.1
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Accept: */*
Referer: http://www.mysite.com/test-forum/477352-test.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: bblastvisit=1319205053; bblastactivity=0; bbuserid=265374; bbpassword=1125e9ec1ab41f532ab8ec6f77ddaf94; bbsessionhash=91444317c100996990a04d6c5bbd8375;
Body
securitytoken=1319806096-618e5f9012901e2d818bf2c74c2121baa064be57&ajax=1&ajax_lastpost=1319806096&**message=%u00E4%u00F6%u00F5%u00FC%u00E4%u00F6%u00F5%u00FC%u00E4%u00F6%u00F5%u00FC%u00E4%u00F6%u00F5%u00FC**&wysiwyg=0&styleid=1&signature=1&fromquickreply=1&s=&do=postreply&t=477352&p=who%20cares&specifiedpost=0&parseurl=1&loggedinuser=265374
As we can see in the request body 'äöõüäöõüäöõüäöõü is encoded as: %u00E4%u00F6%u00F5%u00FC%u00E4%u00F6%u00F5%u00FC%u00E4%u00F6%u00F5%u00FC%u00E4%u00F6%u00F5%u00FC
Now i want to replicate it.
Lets Url encode the text with charset utf-8 in Java:
String userText = "äöõüäöõüäöõüäöõü";
String encoded = URLEncoder.encode(userText, "utf-8");
Result: %C3%A4%C3%B6%C3%B5%C3%BC%C3%A4%C3%B6%C3%B5%C3%BC%C3%A4%C3%B6%C3%B5%C3%BC%C3%A4%C3%B6%C3%B5%C3%BC%0A%0A%0A%5BSIZE%3D%221%22%5D%5BI%5D << NOT THE SAME
Lets try ISO-8859-1:
String userText = "äöõüäöõüäöõüäöõü";
String encoded = URLEncoder.encode(userText, "ISO-8859-1");
Result: %E4%F6%F5%FC%E4%F6%F5%FC%E4%F6%F5%FC%E4%F6%F5%FC%0A%0A%0A%5BSIZE%3D%221%22%5D%5BI%5D << NOT THE SAME
Neither of them produce the same encoded string as in the working example, but all of them have the same input. What am I missing here?
%u00E4%u00F6%u00F5%u00FC%u00E4%u00F6%u00F5%u00FC%u00E4%u00F6%u00F5%u00FC%u00E4%u00F6%u00F5%u00FC
I don't know what the above data is encoded as, but it isn't application/x-www-form-urlencoded; charset=UTF-8 as the request claims. This is not legal data for this MIME type.
It looks like some UTF-16BE-encoded form.
URLEncoder.encode(userText, "utf-8"); would be the correct way to encode the application/x-www-form-urlencoded; charset=UTF-8 values if this was actually what the server was expecting. (ref)
Trying to stream video to windows media player from a servlet (progressive download style). The streaming works, but I have some weird behavior, which I would like to rule out is not caused by a problem in my implementation.
When using WMP to open an url from the servlet, WMP will perform a total of 4 http-get requests for the same resource, but with slightly different headers each time. The connection for the first 3 requests seems to be closed as soon as the request (including headers) have been sent. The fourth request remains connected, and I can actually deliver response headers and the file content.
Have tried using wireshark to watch the first three requests. Identical starts of responses are sent for all 4 requests, and the first 3 requests managed to send the response headers, and some part of the file content before being closed. (Don't know if its relevant, but have to enable "Support packet-capture from IP TSO-enabled hardware" for wireshark to correctly parse the stream, otherwise the first packet containing the http-response is seen as malformed.)
The 4 request headers below here:
GET /basic/test.mpg HTTP/1.1
Accept: */*
User-Agent: Windows-Media-Player/12.0.7600.16415
Accept-Encoding: gzip, deflate
Host: 192.168.1.34
Connection: Keep-Alive
GET /basic/test.mpg HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: getIfoFileURI.dlna.org
Accept: */*
User-Agent: NSPlayer/12.00.7600.16385 WMFSDK/12.00.7600.16385
GetContentFeatures.DLNA.ORG: 1
Host: 192.168.1.34
GET /basic/test.mpg HTTP/1.1
Accept: */*
User-Agent: NSPlayer/12.00.7600.16385 WMFSDK/12.00.7600.16385
Icy-Metadata: 1
Accept-Encoding: gzip, deflate
Host: 192.168.1.34
Connection: Keep-Alive
GET /basic/test.mpg HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: getIfoFileURI.dlna.org
Accept: */*
User-Agent: NSPlayer/12.00.7600.16385 WMFSDK/12.00.7600.16385
GetContentFeatures.DLNA.ORG: 1
Host: 192.168.1.34
Response headers:
HTTP/1.1 200 OK
Content-Type: video/mpeg
Content-Length: 130549760
ETag: TEST1286565215430
ContentFeatures.DLNA.ORG: DLNA.ORG_PN=MPEG_PS_PAL;DLNA.ORG_OP=00
Server: Jetty(6.1.x)
The connection for the first 3 requests seems to be closed as soon as the request (including headers) have been sent.
"Seems to be"? I would find out for certain one way or the before proceeding. If it is ending the connection after the response headers are set, it could be that the player was expecting a very specific header to be present. Examples could include Range: or Cache-Control:.