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.
Related
i'm trying now to upload zip attachment through REST API but no success. It works, when I'm trying to attach picture, but when I use the same command for zip
curl -D- -u Bogdan:Password -X POST -H "X-Atlassian-Token: nocheck"
-F "file=#xla-snapshot.zip" http://localhost:5555/rest/api/2/issue/XA-1/attachments
I have such response:
HTTP/1.1 100 Continue HTTP/1.1 404 Not Found Server: Apache-Coyote/1.1
X-AREQUESTID: 1352x1015x1 X-ASEN: SEN-2117746 Set-Cookie:
JSESSIONID=97A763E5E09F7F8476CEDF07A2ACD7C6; Path=/; HttpOnly
X-Seraph-LoginReason: OK Set-Cookie:
atlassian.xsrf.token=B7X0-QLNV-RIK8-C6T9|aca131a97f4fdb61cebd0bfb6681c66824d62464|lin;
Path=/ X-ASESSIONID: nzll4r X-AUSERNAME: Bogdan Cache-Control:
no-cache, no-store, no-transform X-Content-Type-Options: nosniff
Content-Type: application/json;charset=UTF-8 Transfer-Encoding:
chunked Date: Thu, 20 Nov 2014 21:32:11 GMT
When I modified and explicitly said content type that it is zip
url -D- -u Bogdan:Password -X POST -H "Content-Type:
application/zip" -H "X-Atlassian-Token: nocheck" -F
"file=#xla-snapshot.zip"
http://localhost:5555/rest/api/2/issue/XA-1/attachments
I got an "Unsupported Media Type" response:
HTTP/1.1 100 Continue HTTP/1.1 415 Unsupported Media Type Server:
Apache-Coyote/1.1 X-AREQUESTID: 1353x1016x1 X-ASEN: SEN-2117746
Set-Cookie: JSESSIONID=6225FF25F6D71BADB6890C9F448608B6; Path=/;
HttpOnly X-Seraph-LoginReason: OK Set-Cookie:
atlassian.xsrf.token=B7X0-QLNV-RIK8-C6T9|e2c7fc222c74c37f5080150df1cd865eaa8daf7e|lin;
Path=/ X-ASESSIONID: 1lbjx70 X-AUSERNAME: Bogdan
X-Content-Type-Options: nosniff Content-Type: text/html;charset=utf-8
Content-Language: en Content-Length: 1092 Date: Thu, 20 Nov 2014
21:33:07 GMT
Is it possible actually to upload archives via REST Api?
Actually the problem was that the file was too big for download, the limit is 10 Mb, and I was trying to upload more than it.
Quite sad that looking at this documentation https://docs.atlassian.com/jira/REST/latest/#d2e4527 there is no information about 404, when it can happen. And no information how you can guess the real cause
I am verifying if my application handles file content delivered through chunked-encoding mode. I am not sure what change to make to the httpd.conf file to force chunked encoding through Apache. Is it even possible to do this with Apache server, if not what would be an easier solution? I am using Apache 2.4.2 and HTTP 1.1.
By default, keep-alive is On in Apache and I do not see the data as chunked when testing with wireshark.
EDIT: Added more info:
Only way I managed to do this was by enabling the deflate module.
Then I configured my client to send "Accept-Encoding: gzip, deflate" header and apache would compress and send the file back in chunked mode.
I had to enable the file type in the module though.
AddOutputFilterByType DEFLATE image/png
See example:
curl --raw -v --header "Accept-Encoding: gzip, deflate" http://localhost/image.png | more
* Connected to localhost (127.0.0.1) port 80 (#0)
> GET /image.png HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost
> Accept: */*
> Accept-Encoding: gzip, deflate
>
< HTTP/1.1 200 OK
< Date: Mon, 13 Apr 2015 10:08:45 GMT
* Server Apache/2.4.7 (Ubuntu) is not blacklisted
< Server: Apache/2.4.7 (Ubuntu)
< Last-Modified: Mon, 13 Apr 2015 09:48:53 GMT
< ETag: "3b5306-5139805976dae-gzip"
< Accept-Ranges: bytes
< Vary: Accept-Encoding
< Content-Encoding: gzip
< Transfer-Encoding: chunked
< Content-Type: image/png
<
This resource produces chunked results http://www.httpwatch.com/httpgallery/chunked/
which is very useful for testing clients. You can see this by running
$ curl --raw -i http://www.httpwatch.com/httpgallery/chunked/
HTTP/1.1 200 OK
Cache-Control: private,Public
Transfer-Encoding: chunked
Content-Type: text/html
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Mon, 22 Jul 2013 09:41:04 GMT
7b
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
2d
<html xmlns="http://www.w3.org/1999/xhtml">
....
I tried this way to get HTTP chunked encoded data in Ubuntu, it might help.
In apache server create a file index.php in your directory where index page is there ( ex : /var/www/html/) and paste below content (should have php installed):
<?php phpinfo(); ?>
Then try to curl the page as below :
root#ubuntu-16:~# curl -v http://10.11.0.230:2222/index.php
* Trying 10.11.0.230...
* Connected to 10.11.0.230 (10.11.0.230) port 2222 (#0)
> GET /index.php HTTP/1.1
> Host: 10.11.0.230:2222
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Wed, 01 Jul 2020 07:51:24 GMT
< Server: Apache/2.4.18 (Ubuntu)
< Vary: Accept-Encoding
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=UTF-8
<
<!DOCTYPE html>
<html>
<body>
...
...
...
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.
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>
...
I'm building a JSON API on top of devise in order to be able to communicate from mobile devices.
So far so good, I am able to create a user account, to get an auth_token. But when I am trying to perform a PUT request, I get some problems , for example the update action for the user. The behavior is really stange, and I can't figure out what is wrong.
curl -i -H "Accept: application/json" 'http://localhost:3000/users' -X PUT -d 'auth_token=A830ALUv7ztTdSfl3qxFgi13BJpEf6VzNYe4yk8rEhVxbYYlOc0YMtTGMxkz&user[name]=plop'
Returns
HTTP/1.1 401 Unauthorized
Connection: close
Date: Wed, 02 Mar 2011 06:41:29 GMT
Content-Type: application/json; charset=utf-8
Cache-Control: no-cache
X-UA-Compatible: IE=Edge
X-Runtime: 0.157513
Transfer-Encoding: chunked
{"error":"You need to sign in or sign up before continuing."}
On the logs on the server i get this .... Really strange.
Started PUT "/users" for 127.0.0.1 at 2011-03-01 22:41:29 -0800
Processing by Users::RegistrationsController#update as JSON
Parameters: {"auth_token"=>"A830ALUv7ztTdSfl3qxFgi13BJpEf6VzNYe4yk8rEhVxbYYlOc0YMtTGMxkz", "user"=>{"name"=>"plop"}}
Completed in 1ms
Whereas if I modify just the name of the post value from user to users form example, the request works
HTTP/1.1 200 OK
Connection: close
Date: Wed, 02 Mar 2011 06:43:30 GMT
Content-Type: application/json; charset=utf-8
ETag: "5e1311709931861e469ce2c8a3b2d0e6"
Cache-Control: max-age=0, private, must-revalidate
X-UA-Compatible: IE=Edge
Set-Cookie: _u_session=BAh7CEkiGXdhcmRlbi51c2VyLnVzZXIua2V5BjoGRVRbCEkiCVVzZXIGOwBGWwZvOhNCU09OOjpPYmplY3RJZAY6CkBkYXRhWxFpUGGaQG%2FaX1pAfhpAaRpAexpAGkAaQ1JIiIkMmEkMTAkMDVBeDczV29UdVFEZHQxZ1JjN0NXdQY7AFRJjW9uRGlzcGF0Y2g6OkZsYXNoOjpGbGFzaEhhc2h7BjoLbm90aWNlSSIrWW91IHVwZGF0ZWQgeW91ciBhY2NvdW50IHN1Y2Nlc3NmdWxseS4GOwBUBjoKQHVzZWRvOghTZXQGOgpAaGFzaHsASSIPc2Vzc2lvbl9pZAY7AEYiJTcyNmIyZjJiODZhOTBiNjUwZDlhZmIwMzA5MTRkMTlm--0e15953fd7edecb0e08255349c4e55f1eddc8d81; path=/; HttpOnly
X-Runtime: 0.162436
Transfer-Encoding: chunked
{"redirect":"/","status":"ok"}
I precise that, even without my code(For the API) I can't perform this request !!!!
Thanks for your help !
I don't believe that Devise handles JSON calls, there is an open issue on github that is scheduled for the 1.3 release to address this problem.