Intermittent failure to deliver static content from tomcat - http

I have a javascript file (and have seen this with other static content) that is sometimes not being delivered correctly by tomcat, despite a 200 response. I have tried server versions 6.0.18 and 6.0.33 with the same result. Below is an example of the result I see using wget to request the same item several times, feel free to try yourself if that helps:
--20:00:46-- http://t-pen.org/TPEN/transcription.js
=> `transcription.js.28'
Resolving t-pen.org... 165.134.241.71
Connecting to t-pen.org|165.134.241.71|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified
(See no mime type)
--20:01:06-- http://t-pen.org/TPEN/transcription.js
=> `transcription.js.29'
Resolving t-pen.org... 165.134.241.71
Connecting to t-pen.org|165.134.241.71|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 97,373 (95K) [text/javascript]
The problem in the browser is a message stating that the mime type for the javascript is incorrect. I havent messed with the mime type configuration in tomcat, and it comes through correctly most times, so I really dont know where I can look to try to solve this. Any help is much appreciated.
curl output for problematic GET:
$ curl -v http://t-pen.org/TPEN/transcription.js > /dev/null
> GET /TPEN/transcription.js HTTP/1.1
> User-Agent: curl/7.21.6 (i686-pc-linux-gnu) libcurl/7.21.6 OpenSSL/1.0.0e zlib/1.2.3.4 libidn/1.22 librtmp/2.3
> Host: t-pen.org
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Transfer-Encoding: chunked
< Date: Thu, 27 Oct 2011 20:43:55 GMT
<
{ [data not shown]
100 97373 0 97373 0 0 86338 0 --:--:-- 0:00:01 --:--:-- 112k
and normal one:
$ curl -v http://t-pen.org/TPEN/transcription.js > /dev/null
> GET /TPEN/transcription.js HTTP/1.1
> User-Agent: curl/7.21.6 (i686-pc-linux-gnu) libcurl/7.21.6 OpenSSL/1.0.0e zlib/1.2.3.4 libidn/1.22 librtmp/2.3
> Host: t-pen.org
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< ETag: W/"97373-1319761050000"
< Last-Modified: Fri, 28 Oct 2011 00:17:30 GMT
< Content-Type: text/javascript
< Content-Length: 97373
< Date: Thu, 27 Oct 2011 20:45:21 GMT
<
{ [data not shown]
100 97373 100 97373 0 0 86196 0 0:00:01 0:00:01 --:--:-- 112k

Our solution to the problem is to move static content to a location served by apache and then use AJP through apache rather than direct requests to tomcat, because the AJP requests are serviced by the AJP connector rather than the HTTP/1.1 connector which is causing our troubles. This doesnt fully explain the cause of the issue, but this is how we are working around it.

Related

How to respond 'Expect: 100-continue' header in shelf [server]

I am using curl cli to upload a file to my shelf server, request contains header Expect: 100-continue, now curl abort by curl: (52) Empty reply from server, the correct responding seems server should 2 status codes(100 and 200):
> POST /upload HTTP/1.1
> Host: 0.0.0.0:8000
> User-Agent: curl/7.64.0
> Accept: */*
> Content-Length: 26252
> Content-Type: multipart/form-data; boundary=------------------------c9c343811f9aee88
> Expect: 100-continue
>
* Expire in 1000 ms for 0 (transfer 0x2f156ed0)
< HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
< Date: Thu, 22 Sep 2022 01:51:25 GMT
If client not using header Expect: to avoid this case, what should I do to implement '2-status' in shelf server end? Thanks!

A strange problem about size limit in http header

Context: I maintain a kind of web service server, but with a particular implementation: all data sent by the web services are located in the http header. That means there is only http header in the response (no body part). The web service runs as a windows service. The consumer is my PHP code which invokes the web service via CURL library. All this is in production since 3 years and works fine. I recently had to build a development environment.
I have the web service on a Windows 7 pro, as a windows service.
I have my PHP consumer in another windows 7 pro (WAMP + CURL).
my PHP code invokes the web service and displays the raw response.
in this context the problem occurs: if the response contains more than 1215 characters, I have an empty response (but no error message).
I installed my PHP code (exactly the same) on a new Linux ubuntu: I have the same problem.
I installed my PHP code (exactly the same) on a new Linux centos: I DON'T HAVE THE PROBLEM.
I read a lot on internet about size limitation on http header, and I think today it's not the reason of the problem.
I examined all size limitation parameters on Apache, PHP, Curl but I didn't find something relevant.
If someone has some information. All tracks are welcome. Thanks
not an answer, but want to say that using PHP 7.2.5 under mod_php with Apache 2.4.33, i am unable to reproduce your issue, as i have no problems sending anything from 1 byte to 10,000 to even 100,000 bytes in headers:
here is my producer.php:
<?php
$size=((int)($_GET['s'] ?? 1));
header("X-size: {$size}");
$data=str_repeat("a",$size);
header("X-data: {$data}");
http_response_code(204); // 204 NO CONTENT
and whether i hit http://127.0.0.1/producer.php?s=1 or http://127.0.0.1/producer.php?s=10000 or even http://127.0.0.1/producer.php?s=100000 , the data is returned without issue, as you can see in the screenshot above. can you reproduce the issue using my producer.php code?
btw, interestingly, when i try 1 million bytes, i get this error from curl:
$ curl -I http://127.0.0.1/producer.php?s=1000000
HTTP/1.1 204 No Content
Date: Wed, 16 Jan 2019 20:11:25 GMT
Server: Apache/2.4.33 (Win32) OpenSSL/1.1.0h PHP/7.2.5
X-Powered-By: PHP/7.2.5
X-size: 1000000
curl: (27) Rejected 104960 bytes header (max is 102400)!
Hanshenrik,
i also used CURLOPT_VERBOSE as you said. Here are the 2 curl logs.
The only difference is the line
<* stopped the pause stream!> in the Ubuntu curl log.
CURL log from Ubuntu witch has the probleme:
* Trying 192.168.1.205...
* TCP_NODELAY set
* Connected to 192.168.1.205 (192.168.1.205) port 8084 (#0)
> POST /datasnap/rest/TServerMethods/%22W_GetDashboard%22/ HTTP/1.1
Host: 192.168.1.205:8084
Accept-Encoding: gzip,deflate
Accept: application/json
Content-Type: text/xml; charset=utf-8
Pragma: dssession=146326.909376.656191
Content-Length: 15
* upload completely sent off: 15 out of 15 bytes
< HTTP/1.1 200 OK
< Connection: close
< Content-Encoding: deflate
< Content-Type: application/json
< Content-Length: 348
< Date: Thu, 17 Jan 2019 15:27:03 GMT
< Pragma: dssession=146326.909376.656191,dssessionexpires=3600000
<
* stopped the pause stream!
* Closing connection 0
CURL log from Centos witch has NOT the probleme:
* About to connect() to 192.168.1.205 port 8084 (#1)
* Trying 192.168.1.205...
* Connected to 192.168.1.205 (192.168.1.205) port 8084 (#1)
> POST /datasnap/rest/TServerMethods/%22W_GetDashboard%22/ HTTP/1.1
Host: 192.168.1.205:8084
Accept-Encoding: gzip,deflate
Accept: application/json
Content-Type: text/xml; charset=utf-8
Pragma: dssession=3812.553164.889594
Content-Length: 15
* upload completely sent off: 15 out of 15 bytes
< HTTP/1.1 200 OK
< Connection: close
< Content-Encoding: deflate
< Content-Type: application/json
< Content-Length: 348
< Date: Thu, 17 Jan 2019 15:43:39 GMT
< Pragma: dssession=3812.553164.889594,dssessionexpires=3600000
<
* Closing connection 1

How to successfully resend a POST request and get the correct respond without knowing the actual payload

I've been working on to capture a multiple post requests from an android app for testing purpose.
Unfortunately, I'm stuck in finding a way to get the actual payload of the request by using a request sender to resend the request. I could get 200 status code but I could only get a wrong respond, and that is not what I expected. I'm hoping to get any advice in here if it's possible?
The request is sent via a POST method.
The request address looks like this(from my perspective it doesn't have a body, does it?)
http://proxy.ABC.ABC.com/ABC/qryunreadmsgcount.do?d=2&m=1&t=803514
Please correct me if the description or the title needs further editing .
Cheers
=========================================================================
Edit:
this is the respond that I got
Preview: {
"respbase": {
"status": "false",
"returncode": "000002",
"returndesc": "必填参数[clientrequest]"
}
}
Server: nginx/1.14.0
Date: Thu, 19 Jul 2018 01:44:38 GMT
Content-Type: application/json;charset=UTF-8
Content-Length: 4
Connection: keep-alive
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type, Accept-Language, Origin, Accept-Encoding
X-Frame-Options: SAMEORIGIN
* Preparing request to http://proxy.ABC.ABC.com/vboxserver/qryunreadmsgcount.do?d=2&m=1&t=803514
* Using libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
* Enable automatic URL encoding
* Enable SSL validation
* Enable cookie sending with jar of 7 cookies
* Trying 101.XXX.XXX.XXX...
* TCP_NODELAY set
* Connected to proxy.ABC.ABC.com (101.xxx.xxx.xxx) port 80 (#75)
> POST /ABC/qryunreadmsgcount.do?d=2&m=1&t=803514 HTTP/1.1
> Host: proxy.ABC.ABC.com
> User-Agent: insomnia/5.16.6
> Accept: */*
> Content-Length: 0
< HTTP/1.1 200 OK
< Server: nginx/1.14.0
< Date: Thu, 19 Jul 2018 02:13:24 GMT
< Content-Type: text/plain
< Content-Length: 96
< Connection: keep-alive
< X-Frame-Options: SAMEORIGIN
* Received 88 B chunk
* Connection #75 to host proxy.ABC.ABC.com left intact
And this is the request sender I've been using:
For those who might want to know the answer:
Burpsuite is very handy in dealing with this
:)

cURL not returning after receiving 404 response

I have a webserver I have made in C (school project)
It seems to handle 200 response codes fine. However when i try to use cURL to test 404, it doesn't return/exit.
For example:
$ curl localhost:5555/q.txt
...
If I use verbose.
$ curl -v localhost:5555/q.txt
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 5555 (#0)
> GET /q.txt HTTP/1.1
> User-Agent: curl/7.40.0
> Host: localhost:5555
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 404 Not Found
< Date: Fri, 14 Aug 2015 11:16:32 AEST
< Connection: close
< Server: myserver/jnd
<
The full message I am sending back is:
HTTP/1.0 404 Not Found\r\nDate: Fri, 14 Aug 2015 11:18:10 AEST\r\nConnection: close\r\nServer: myserver/jnd\r\n\r\n
Am I missing something here? A new-line or other formatting?
It seems cURL will just wait until you close the connection.
So if I just close(fd) afterwards, it works.

Heroku router closing persistent http/1.1 connection requests?

I have a application hosted on Heroku, and it seems to be adding a Connection:close to the response header of a HTTP/1.1 connection request, and not allowing us to re-use a persistent HTTP/1.1 connection. This works for other apps I have on Heroku, but I can't figure out why it would do this for this app. Any clues?
So if I attempt to test with curl for example,
curl -v "http://myapp.herokuapp.com/api/posts/trending" "http://myapp.com/api/posts/trending"
* Connected to myapp.herokuapp.com () port 80 (#0)
> GET /api/posts/trending HTTP/1.1
> User-Agent: curl/7.37.1
> Host: myapp.herokuapp.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Connection: close
< Date: Mon, 09 Mar 2015 20:54:15 GMT
< Cache-Control: no-cache, no-store, must-revalidate
< Pragma: no-cache
< Expires: 0
< Content-Type: application/json;charset=UTF-8
* Server Jetty(9.2.7.v20150116) is not blacklisted
< Server: Jetty(9.2.7.v20150116)
< Via: 1.1 vegur
...response...
* Closing connection 0
Answering my own question here, according to Heroku Support, it is known limitation of the Heroku router, since Jetty doesn't send Connection: keep-alive in the response of HTTP/1.1 request by design. No suggested workarounds at this time.

Resources