I am testing a CGI that locally is working fine as HTML, but when executed from DreamHost it shows as text:
http://www.fivetechsoft.net/cgi-bin/tutor01.cgi
If executed locally it shows fine:
localhost/cgi-bin/tutor01.cgi
Any hints why it is not seen as HTML from DreamHost ? Content-Type is properly set as "Content-Type: text/html", thanks
Antonio
Looks like your Apache is sending some bogus headers, seems to be ANSI escape codes. Which means your Content-Type line is not valid, and Apache replaces it with its default Content-Type.
$ curl -si http://www.fivetechsoft.net/cgi-bin/tutor01.cgi | less
HTTP/1.1 200 OK
Date: Sat, 27 Oct 2012 20:31:38 GMT
Server: Apache
ESC[0mESC[1;1HESC[?25hESC[0;10;37;40mESC[mContent-Type: text/html
Transfer-Encoding: chunked
Content-Type: text/plain
<html>
<head>
...
Related
I've build a simple internet radio using ESP8266+VS1053. It works.
The query sent to icecast server looks like:
GET / HTTP/1.1
User-Agent: Windows-Media-Player/10.00.00.1111
Host: 66.85.88.242
Icy-Metadata:1
Accept: audio/mpeg,audio/aacp
Connection: keep-alive
SOME stations works fine, while others returns html instead of stream data. For example:
SheRadio: http://66.85.88.242:8136/1139_128 -- returns
HTTP/1.1 200 OK
Content-Length: 501
Content-Type: text/html
Date: Fri, 15 Jun 2018 22:05:43 GMT
Server: Icecast 2.4.0-kh3
Cache-Control: no-cache, no-store
Pragma: no-cache
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Origin, Accept, X-Requested-With, Content-Type
Access-Control-Allow-Methods: GET, OPTIONS, HEAD
Connection: Close
Expires: Mon, 26 Jul 1997 05:00:00 GMT
DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<link rel="stylesheet" type="text/css" href="/style.css" />
<title>Icecast Streaming Media Server</title>
(and so on)
instead of:
HTTP/1.0 200 OK
icy-notice1:<BR>This stream requires Winamp<BR>
icy-notice2:SHOUTcast DNAS/posix(linux x64) v2.5.5.733<BR>
Accept-Ranges:none
Access-Control-Allow-Origin:*
Cache-Control:no-cache,no-store,must-revalidate,max-age=0
Connection:close
icy-name:Goldradio Network
icy-genre:60s, 70s, 80s, Top 40, Oldies
icy-br:24
icy-sr:16000
icy-url:http://www.goldradio.org.uk
icy-pub:1
content-type:audio/mpeg
icy-metaint:8192
X-Clacks-Overhead:GNU Terry Pratchett
sent by other stations.
I was completely unable to understand why some worked and some not.
Thanks in advance for any help/ideas.
Please note that you MUST provide the proper path in your HTTP GET request!
GET / HTTP/1.1 is NOT requesting 'http://66.85.88.242:8136/1139_128', but 'http://66.85.88.242:8136/'. The latter is 'text/html' content.
This can be easily verified using:
curl -v --user-agent "Windows-Media-Player/10.00.00.1111" -H "Icy-Metadata: 1" -H "Accept: audio/mpeg,audio/aacp" http://66.85.88.242:8136/ >/dev/null
vs.
curl -v --user-agent "Windows-Media-Player/10.00.00.1111" -H "Icy-Metadata: 1" -H "Accept: audio/mpeg,audio/aacp" http://66.85.88.242:8136/1139_128 >/dev/null
Not sure how it is for ESP8266, but at least for the ESP32, libcurl builds perfectly fine and would be my preferred option for handling HTTP requests instead of error prone hand crafting.
For the first time I've had to wrap something I'm working on as a CGI script. I'm having trouble with browsers (Both both Chrome and Firefox) not recognising the Content-Length header and stating size "unknown" to the users.
When I test this with the linux too wget, the tool recognises the size just fine.
When I test this manually though openssl s_client -connect I get the following headers:
The precise output from the webserver is as follows:
HTTP/1.1 200 OK
Date: Sun, 30 Jul 2017 20:12:20 GMT
Server: Apache/2.4.25 (Ubuntu) mod_fcgid/2.3.9 OpenSSL/1.0.2g
Content-Disposition: attachment; filename=foo.000000000G-000000001G.foofile.txt;
Content-Length: 501959790
Vary: Accept-Encoding
Content-Type: text/plain;charset=utf-8
Can anyone suggest what is missing / badly formatted?
Cracked it eventually.
This was caused by Apache doing something unexpected. Apache is compressing the output of the CGI script on the fly (sending with Content-Encoding: gzip). This changes the size of the file but Apache cannot know how much it is going to change when it sends the header. The files are 1/GB each so it can't / doesn't cache the gzipped content before it starts sending therefore cannot know the file size. This means it has to switch to Transfer-Encoding: chunked
One way to fix this is set Content-Encoding: none in the header which disables Apache from compressing the content. This does mean that 1/2 GB files take much longer to send.
Another might be to manually gzip the content in my cgi script and setting Content-Encoding: gzip and Content-Length: <gzipped size>. This will require me to work out the compressed size before sending.
I'm failing a PCI compliance scan because my Railo server is revealing the path to the document web root in an "exception-message" header when a missing page is requested. I tried using both the built-in Railo 404 template and my own custom 404 template to no avail. Is there anyway to get rid of this header from the reponse?
$ curl -I http://mydomain.com/this-page-does-not-exist.html
HTTP/1.1 200 OK
Date: Wed, 08 Jan 2014 22:46:20 GMT
Server: Apache-Coyote/1.1
exception-message: Page /this-page-does-not-exist.html [/var/www/html/this-page-does-not-exist.html] not found
Content-Type: text/html;charset=UTF-8
Content-Length: 44
Set-Cookie: CFID=31254774-4b81-470d-b0da-dfadd4585ce0;Path=/;Expires=Fri, 08-Jan-2044 06:37:50 GMT
Set-Cookie: CFTOKEN=0;Path=/;Expires=Fri, 08-Jan-2044 06:37:50 GMT
Connection: close
Update: I was able to fix this problem by overwriting the header.
I created a custom 404 template and then set the Missing Template Error (404) option to point at it in the Railo administrator. Then I added this line of code to the top of the page which seems to overwrite the header with a blank string.
<cfset getPageContext().getResponse().setHeader("exception-message","")>
Note: Using the tag <cfheader> to do the same thing does not work. I'm not sure why but the Java route seems to do the trick.
I use gwan for image generation, so I need to set correct content type, but G-WAN 3.12.26 after some load adds its own header with content type text/html and returns page with 2 http headers.
How to reproduce this:
use setheaders.c servlet from gwan package, start gwan and open this page, lets say http://localhost/?setheaders.c and you will get this (correct response):
HTTP/1.1 200 OK
Date: Sat, 29 Dec 2012 20:37:52 GMT
Last-Modified: Sat, 29 Dec 2012 20:37:52 GMT
Content-type: text/html
Content-Length: 371
Connection: close
<!DOCTYPE HTML><html lang="en"><head><title>Setting response headers</title><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><link href="imgs/style.css" rel="stylesheet" type="text/css"></head><body style="margin:16px;"><h1>Setting response headers</h1><br>This reply was made with custom HTTP headers, look at the servlet source code.<br></body></html>`
now run apache bench: ab -n 1000 'http://localhost/?setheaders.c' (1000 requests were enough for my system).
DO NOT RESTART GWAN, open http://localhost/?setheaders.c again and this is what you should get (incorrect response, 2 http headers):
HTTP/1.1 200 OK
Server: G-WAN
Date: Sat, 29 Dec 2012 20:43:34 GMT
Last-Modified: Fri, 16 Jan 1970 16:53:33 GMT
ETag: "be86ada7-14b40d-16f"
Vary: Accept-Encoding
Accept-Ranges: bytes
Content-Type: text/html; charset=UTF-8
Content-Length: 367
Content-Encoding: gzip
Connection: close
HTTP/1.1 200 OK
Date: Sat, 29 Dec 2012 20:43:34 GMT
Last-Modified: Sat, 29 Dec 2012 20:43:34 GMT
Content-type: text/html
Content-Length: 371
Connection: close
<!DOCTYPE HTML><html lang="en"><head><title>Setting response headers</title><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><link href="imgs/style.css" rel="stylesheet" type="text/css"></head><body style="margin:16px;"><h1>Setting response headers</h1><br>This reply was made with custom HTTP headers, look at the servlet source code.<br></body></html>
GWAN returns correct response if gzip and x-gzip are not set as acceptable encoding in request header (Accept-Encoding: gzip, x-gzip).
Is it possible to solve this modifying just servlet? If yes, then how?
Are you setting the MIME type like shown in fractal.c:
// -------------------------------------------------------------------------
// specify a MIME type so we don't have to build custom HTTP headers
// -------------------------------------------------------------------------
char *mime = (char*)get_env(argv, REPLY_MIME_TYPE);
// note that we setup the FILE EXTENTION, not the MIME type:
mime[0] = '.'; mime[1] = 'g'; mime[2] = 'i'; mime[3] = 'f'; mime[4] = 0;
If you do so then there's no way to confuse the automatic headers feature.
Other than that, v3.12 has had many instability problems (file time failures, pthread failures, signals failures, etc.) due to our direct syscalls and GLIBC wrappers - an effort initially intended to make the program run on all versions of Linux.
We have found (thanks to the many reports like yours) that rather than trying to fix those issues one by one (pointlessly fighting GLIBC, a moving target with many different releases each having its own bugs and specificities) a much safer path is to ditch GLIBC.
That's what G-WAN v4 will do, just a few days from now.
When using the HTTP API I am trying to make a call to the aliveness-test for monitoring purposes. At the moment I am testing using curl and the following command:
curl -i http://guest:guest#localhost:55672/api/aliveness-test/
And I get the following response:
HTTP/1.1 404 Object Not Found
Server: MochiWeb/1.1 WebMachine/1.9.0 (someone had painted it blue)
Date: Mon, 05 Nov 2012 17:18:58 GMT
Content-Type: text/html
Content-Length: 193
<HTML><HEAD><TITLE>404 Not Found</TITLE></HEAD><BODY><H1>Not Found</H1>The requested document was not found on this server.<P><HR><ADDRESS>mochiweb+webmachine web server</ADDRESS></BODY></HTML>
When making a request just to list the users or vhosts, the requests returns successfully:
$ curl -I http://guest:guest#localhost:55672/api/users
HTTP/1.1 200 OK
Server: MochiWeb/1.1 WebMachine/1.9.0 (someone had painted it blue)
Date: Mon, 05 Nov 2012 17:51:44 GMT
Content-Type: application/json
Content-Length: 11210
Cache-Control: no-cache
I'm using the latest stable version (2.8.7) of RabbitMQ and obviously have the management plugin installed for the API to work with the users call (the response is left out due to it containing company data but is just regular JSON as expected).
There isn't much on the internet about this call failing so I am wondering if anyone has seen this before?
Thanks,
Kristian
Turns out that the '/' at the beginning of the vhosts names is not implicit, even when as part of a URL. To get this to work I simply changed my request from:
curl -i http://guest:guest#localhost:55672/api/aliveness-test/
To
curl -i http://guest:guest#localhost:55672/api/aliveness-test/%2F
As %2F is '/' HTTP encoded, my request now queries the vhost named '/' and returns a 200 response which looks like:
{"status":"ok"}