I'm building a Node.js program and I've gotten a fairly good music streaming method down. But for some reason, the audio is only streaming in FireFox (not in Chrome). I've provided a sample link for a song I know isn't working here. I'm almost positive this is a header issue. What should I change to get everything working smoothly?
Note: If the above url says "No App Running" or something along those lines, wait about an hour and try again. I'm currently knee-deep in development.
Two requests are made by Chrome:
GET https://mesh-c9-triforce1.c9.io/stream/Katrah-Query/Rainfall%20Roots HTTP/1.1
Host: mesh-c9-triforce1.c9.io
Connection: keep-alive
Cache-Control: max-age=0
Accept-Encoding: identity;q=1, *;q=0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36
Accept: */*
Referer: https://mesh-c9-triforce1.c9.io/stream/Katrah-Query/Rainfall%20Roots
Accept-Language: en-US,en;q=0.8
Range: bytes=0-
And:
GET https://mesh-c9-triforce1.c9.io/stream/Katrah-Query/Rainfall%20Roots HTTP/1.1
Host: mesh-c9-triforce1.c9.io
Connection: keep-alive
Cache-Control: max-age=0
Accept-Encoding: identity;q=1, *;q=0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36
Accept: */*
Referer: https://mesh-c9-triforce1.c9.io/stream/Katrah-Query/Rainfall%20Roots
Accept-Language: en-US,en;q=0.8
Range: bytes=2808-
The response headers are the same for both:
HTTP/1.1 200 OK
x-powered-by: Express
last-modified: Wed, 12 Mar 2014 08:56:38 GMT
date: Thu, 18 Sep 2014 23:40:14 GMT
expires: Thu, 18 Sep 2014 23:40:14 GMT
content-type: audio/mp4; codecs="mp4a.40.2"
accept-ranges: bytes
content-length: 4754197
Related
I am running a Python Flask server. A co-worker added Flasgger/Swagger support and I can successfully display the API using
http://localhost:5000/apidocs
Similarly, I can get the json version of the API
http://localhost:5000/api_documentation.json
Python code configures that filename
That same code is deployed in an Openshift project and uses Traefik to route external requests to the Python Flask server
https://my-openshift-url-here/apidocs
does not display the API
only displays "Powered by Flasgger 0.9.5
https://my-openshift-url-here/api_documentation.json
works same as the localhost request
Traefik keys off of the "apidocs" and "api_documentation.json" and routes it directly to the Python Flask server
rule: PathPrefix(`/apidocs`)
entryPoints:
- web
middlewares:
- gzip
- mysecurity-no-token
service: my-python-server
apidocumentation:
rule: PathPrefix(`/api_documentation.json`)
entryPoints:
- web
middlewares:
- gzip
- mysecurity-no-token
service: my-python-server
What I see in my Chrome browser debugger (F12 - Network) for the swagger-ui-bundle.js response is "You need to enable JavaScript to run this app."
Why does this work in Chrome for the localhost version but not when accessing the server deployed on Openshift? Both are being accessed from the same Chrome window - just different tabs.
This is the Headers content of the apidocs request for the localhost version
Request Method: GET
Status Code: 200 OK
Remote Address: 127.0.0.1:5000
Referrer Policy: strict-origin-when-cross-origin
Content-Length: 3041
Content-Type: text/html; charset=utf-8
Date: Thu, 19 Aug 2021 12:08:41 GMT
Server: Werkzeug/2.0.1 Python/3.7.4
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cache-Control: no-cache
Connection: keep-alive
Host: localhost:5000
Pragma: no-cache
sec-ch-ua: "Chromium";v="92", " Not A;Brand";v="99", "Google Chrome";v="92"
sec-ch-ua-mobile: ?0
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36
This is the Headers content of the apidocs request for the Openshift version
Request Method: GET
Status Code: 200 OK
Remote Address: 123.456.789.123:443 (obfuscated, of course)
Referrer Policy: origin
content-encoding: gzip
content-length: 1264
content-type: text/html; charset=utf-8
date: Thu, 19 Aug 2021 12:08:59 GMT
server: istio-envoy
vary: Accept-Encoding
x-envoy-upstream-service-time: 28
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cache-Control: no-cache
Connection: keep-alive
Host: my-openshift-server-url-here
Pragma: no-cache
sec-ch-ua: "Chromium";v="92", " Not A;Brand";v="99", "Google Chrome";v="92"
sec-ch-ua-mobile: ?0
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36
Turns out it was a Traefik routing issues. After the initial response to the /apidocs request, it was also making requests to /flasgger_static/foo. I had to add a route for flassgger_static in my Traefik routing table.
flassger:
rule: PathPrefix(`/flasgger_static`)
entryPoints:
- web
middlewares:
- gzip
- mysecurity-no-token
service: my-python-server
Why does browser (Chrome) keep sending GET requests for SSE (Server-Sent Events)? Any idea why?
I only run the 'subscribeMe' function below once via clicking on button on the HTML page.
I understand that SSE works by only one GET is sent, and one 200 OK is received .. then with changes, server only pushes "data: ....." through the kept-open TCP HTTP/HTTPS connection.
const state = ['connecting', 'open', 'closed'];
let EPEvent;
function subscribeMe() {
EPEvent = new EventSource(`/event/${window.sessionStorage.getItem("Token")}/EPRegistration`);
EPEvent.onmessage = function (e) { console.log(state[this.readyState]); console.log(e); console.log(JSON.parse(e.data)) }
EPEvent.onopen = function () { console.log(state[this.readyState]) }
}
GET /event/MTSE-960a8337-1f95-495c-a313-92659ba8ba5d/EPRegistration HTTP/1.1
Host: 192.168.1.2
Connection: keep-alive
Accept: text/event-stream
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
Referer: http://192.168.1.2/manage
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: text/event-stream
Cache-Control: no-cache
Date: Sun, 08 Mar 2020 21:07:45 GMT
Server: Home SE
Content-Length: 14
data: null
GET /event/MTSE-960a8337-1f95-495c-a313-92659ba8ba5d/EPRegistration HTTP/1.1
Host: 192.168.1.2
Connection: keep-alive
Accept: text/event-stream
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
Referer: http://192.168.1.2/manage
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
HTTP/1.1 200 OK
Cache-Control: no-cache
Connection: keep-alive
Content-Type: text/event-stream
Date: Sun, 08 Mar 2020 21:07:48 GMT
Server: Home SE
Content-Length: 14
data: null
GET /event/MTSE-960a8337-1f95-495c-a313-92659ba8ba5d/EPRegistration HTTP/1.1
Host: 192.168.1.2
Connection: keep-alive
Accept: text/event-stream
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
Referer: http://192.168.1.2/manage
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
HTTP/1.1 200 OK
Cache-Control: no-cache
Connection: keep-alive
Content-Type: text/event-stream
Date: Sun, 08 Mar 2020 21:07:51 GMT
Server: Home SE
Content-Length: 14
data: null
GET /event/MTSE-960a8337-1f95-495c-a313-92659ba8ba5d/EPRegistration HTTP/1.1
Host: 192.168.1.2
Connection: keep-alive
Accept: text/event-stream
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
Referer: http://192.168.1.2/manage
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
HTTP/1.1 200 OK
Cache-Control: no-cache
Connection: keep-alive
Content-Type: text/event-stream
Date: Sun, 08 Mar 2020 21:07:54 GMT
Server: Home SE
Content-Length: 14
data: null
GET /event/MTSE-960a8337-1f95-495c-a313-92659ba8ba5d/EPRegistration HTTP/1.1
Host: 192.168.1.2
Connection: keep-alive
Accept: text/event-stream
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
Referer: http://192.168.1.2/manage
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
HTTP/1.1 200 OK
Cache-Control: no-cache
Connection: keep-alive
Content-Type: text/event-stream
Date: Sun, 08 Mar 2020 21:07:57 GMT
Server: Home SE
Content-Length: 14
data: null
GET /event/MTSE-960a8337-1f95-495c-a313-92659ba8ba5d/EPRegistration HTTP/1.1
Host: 192.168.1.2
Connection: keep-alive
Accept: text/event-stream
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
Referer: http://192.168.1.2/manage
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
HTTP/1.1 200 OK
Cache-Control: no-cache
Connection: keep-alive
Content-Type: text/event-stream
Date: Sun, 08 Mar 2020 21:08:00 GMT
Server: Home SE
Content-Length: 14
data: null
Fixed it!
I should have not put 'Content-Length' in my response! .. This is a stream, Content-Length has no meaning.
Now, it is working fine.
So I have a small widget that is running on a lot of third party websites with no issues. However on one of the sites it is unable to make any JSONP requests to get more data. It is using the $http service from angularjs 1.2.x to make the request and when I look at the request I am seeing a status code of 0 and looking at the Chrome Network tab I don't see any network traffic as a result of the JSONP request so it seems that perhaps a setting on the site is disabling the JSONP request. Below are the headers for the site. Would any of these disable JSONP?
Request Method: GET
Status Code: 200
Referrer Policy: no-referrer-when-downgrade
age: 67
cache-control: max-age=180
content-encoding: gzip
content-length: 31663
content-security-policy: upgrade-insecure-requests;
content-type: text/html;charset=UTF-8
date: Tue, 09 Apr 2019 21:05:47 GMT
server: Apache-Coyote/1.1
status: 200
vary: Accept-Encoding
x-amz-cf-id: _2wi32jNFBQKDwJO9eZroHcZrY74J56d-guSmRCCf6aoCpLDuD4Vzg==
x-cache: Hit from cloudfront
x-powered-by: Brightspot
:authority: www.somesite.com
:method: GET
:path: /entertainment/things/stuff.html
:scheme: https
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
cache-control: no-cache
pragma: no-cache
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.
36
Our one page met some performance issue, during the triage,I found our js files are not cached while other resource like img/css are retrieved from cache(in F12 Network tab, in size column, it shows "from memory cache").
And in Firefox js files are retrieved from cache,this issue only occurred in chrome.
Did someone know the reason?Thanks a lot!
I take a js file request/response for example:
Request Header:
GET /emsaasui/emcpdfui/libs/1.13.0-161128.193454/js/oraclejet/js/libs/require/require.js HTTP/1.1
Host: slc10uan.us.oracle.com:4443
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36
Accept: /
DNT: 1
Referer: https://slc10uan.us.oracle.com:4443/emsaasui/emcpdfui/builder.html?dashboardId=15
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6
Response Header:
HTTP/1.1 200 OK
Date: Tue, 29 Nov 2016 07:59:08 GMT
X-Frame-Options: SAMEORIGIN
Accept-Ranges: bytes
Content-Type: text/javascript; charset=UTF-8
Last-Modified: Tue, 29 Nov 2016 03:38:36 GMT
X-ORACLE-DMS-ECID: 005GajqWd^qDWb85Rjs1yd0006^80000hX
APIGW: true
Set-Cookie: JSESSIONID=DB-vGDHUkRhI0s2oGq-KN_oGs7ToT7oRrZYsz6eXHsMGBgZCxKQv!1414641782; path=/apigw/resources; HttpOnly
Vary: Accept-Encoding
Content-Encoding: gzip
Cache-Control: max-age=2592000
Keep-Alive: timeout=5, max=97
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Language: en
I am setting up a server on ESP8266 WiFi module. Basic operation is, you request a URL. ESP serves that page. It has a form. You fill it in and click submit, and the browser sends POST request by AJAX. I am not using jQuery, just js. From Chrome dev-tools, it looks like all is well.
But on the ESP Server side, I noticed I am missing post data once in a while. After digging deep, I found this issue.
Ideal result from Chrome on my windows: And this works correctly. Post data comes in as expected.
+IPD,0,507:POST /wifi.htm HTTP/1.1
Host: 192.168.4.1
Connection: keep-alive
Content-Length: 63
Origin: http://192.168.4.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Content-Type: text/plain;charset=UTF-8
Accept: */*
Referer: http://192.168.4.1/wifi.htm
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
AlexaToolbar-ALX_NS_PH: AlexaToolbar/alx-4.0
ethOrWiFi=1&ewln=1&dhcp=1&ssid=Esensors&key=tgfgfdgfdtrd&auth=4
But on my Mac Chrome, I see the following result.
+IPD,0,472:POST /wifi.htm HTTP/1.1
Host: 192.168.4.1
Connection: keep-alive
Content-Length: 63
Origin: http://192.168.4.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Content-Type: text/plain;charset=UTF-8
Accept: */*
DNT: 1
Referer: http://192.168.4.1/wifi.htm
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8,ml;q=0.6
AlexaToolbar-ALX_NS_PH: AlexaToolbar/alx-4.0
+IPD,0,63:ethOrWiFi=1&ewln=1&dhcp=1&ssid=Esensors&key=asdfasdfasdf&auth=4
And I can repeat this. The only different in each case is I am using Chrome on Windows as opposed to Chrome on Mac. To double check, I downloaded Chrome canary version and tried. The first request worked fine. From second request onwards, it shows this problem. Why is this happening? Any ideas? May be my laptop has issues? :)
Here are Chrome dev-tools info from Chrome on Mac (the one with the problem)
**Request Headers:**
POST /wifi.htm HTTP/1.1
Host: 192.168.4.1
Connection: keep-alive
Content-Length: 61
Origin: http://192.168.4.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Content-Type: text/plain;charset=UTF-8
Accept: */*
DNT: 1
Referer: http://192.168.4.1/wifi.htm
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8,ml;q=0.6
AlexaToolbar-ALX_NS_PH: AlexaToolbar/alx-4.0
**Request Payload**
ethOrWiFi=1&ewln=1&dhcp=1&ssid=Esensors&key=asdfasdfoi&auth=4
+IPD is the AT command that says data was received from the network. +IPD,0,63: is saying to receive 63 bytes from connection 0. That matches with your Content-Length header. Notice that it also appears at the beginning of the header portion of the request.
Your WiFi library on the ESP side is throwing that in. Here and on line 281 is the source code where it might be happening. There are a couple variables that affect whether or not the +IPD is added, maybe you have set or inadvertently changed one.