The Apple homepage loads some fonts in the head using this tag:
<link rel="stylesheet" href="/wss/fonts?families=SF+Pro,v3|SF+Pro+Icons,v3" type="text/css" media="all">
However, if you visit https://www.apple.com/wss/fonts?families=SF+Pro,v3|SF+Pro+Icons,v3 or try to access via curl
curl --head 'https://www.apple.com/wss/fonts?families=SF+Pro,v3|SF+Pro+Icons,v3'
You get
HTTP/2 403
server: AkamaiGHost
mime-version: 1.0
content-type: text/html
content-length: 280
cache-control: max-age=0
expires: Fri, 17 Feb 2023 20:13:08 GMT
date: Fri, 17 Feb 2023 20:13:08 GMT
x-cache: TCP_DENIED from a2-22-225-45.deploy.akamaitechnologies.com (AkamaiGHost/11.0.0-46340752) (-)
set-cookie: geo=GB; path=/; domain=.apple.com
It would seem that they've set up the server to do something along the lines of the top suggestion here:
https://stackoverflow.com/questions/2187200/using-php-apache-to-restrict-access-to-static-files-html-css-img-etc
I wanted to duplicate exactly what my browser was sending, so I copied the exact request headers (as shown in dev tools) into Postman
accept:text/css,*/*;q=0.1
accept-encoding:gzip, deflate, br
accept-language:en-US,en;q=0.9
cache-control:no-cache
cookie:MY_COOKIE
pragma:no-cache
referer:https://www.apple.com/
sec-ch-ua:"Chromium";v="110", "Not A(Brand";v="24", "Google Chrome";v="110"
sec-ch-ua-mobile:?0
sec-ch-ua-platform:"macOS"
sec-fetch-dest:style
sec-fetch-mode:no-cors
sec-fetch-site:same-origin
user-agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36
But this gets a 404.
But what specifically is the stylesheet sending? Is anything missing?
Related
I loaded an Youtube video, and was checking the Network tab in the Chrome inspector. The weird part is the response header expires show a wrong date, see:
expires:Tue, 27 Apr 1971 19:44:06 EST
Does some one understand if this is correctly implemented (some solution as "the response already arrives expired for security reasons") or is just a bug?
The entire request-response pair:
General
Request URL:https://www.youtube.com/watch?v=Y2bcZpjbimc
Request Method:GET
Status Code:200
Remote Address:216.58.222.14:443
Response Headers
alt-svc:quic=":443"; ma=2592000; v="35,34"
cache-control:no-cache
content-encoding:gzip
content-type:text/html; charset=utf-8
date:Mon, 16 Jan 2017 02:12:59 GMT
expires:Tue, 27 Apr 1971 19:44:06 EST
server:YouTubeFrontEnd
status:200
strict-transport-security:max-age=31536000
x-content-type-options:nosniff
x-frame-options:SAMEORIGIN
x-xss-protection:1; mode=block; report=https://www.google.com/appserve/security-bugs/log/youtube
Request Headers
:authority:www.youtube.com
:method:GET
:path:/watch?v=Y2bcZpjbimc
:scheme:https
accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
accept-encoding:gzip, deflate, sdch, br
accept-language:en-US,en;q=0.8
cache-control:max-age=0
cookie:YSC=tkkR7-gquIo; LOGIN_INFO=09a68a7966aeeb4c54ea2812d67ef17bcz4AAAB7IjMiOiA5ODI4NjMwLCAiMSI6IDEsICI4IjogMTUxMjAxNzQ2Mjg1LCAiNyI6IDAsICI0IjogIkdBSUEifQ==; llbcs=0; SID=KgRtjV-NqZqWb_Vtlx1ZVI4BGeOq6TO0kOwRjM63Y9zRlD8NZ14Ain0S7OHEdAude6Ql5w.; HSID=Ae2Oerx0Cx8cLGNN2; SSID=AAxm-sCogA2PcrWj-; APISID=l63qqbTbXYbA1SWI/ATu8oD872iyWdvAgn; SAPISID=jEgCzttgmiin9s_R/A0u9gLEfrGesFDkOu; _ga=GA1.2.1081395761.1467350952; wide=1; VISITOR_INFO1_LIVE=9ZvTZmoHPqs; C_YNe.resume=nPTuJcnwLro:132,CG1HnKT8khI:1282,0SARbwvhupQ:527; PREF=f1=50000000&f5=20030&al=en+pt&cvdm=grid
dnt:1
upgrade-insecure-requests:1
user-agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
x-client-data:CJG2yQEIprbJAQipncoB
Query String Parameters
v:Y2bcZpjbimc
It is an easter egg left by the original author.
I am using express to write a response.
My code is:
res.set('Cache-Control', 'public, max-age=300');
res.send(data);
The headers I see are:
Remote Address:127.0.0.1:9000
Request URL:http://localhost:9000/some/path
Request Method:GET
Status Code:304 Not Modified
Request Headersview source
Accept:application/json, text/plain, */*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8,he;q=0.6
Cache-Control:max-age=0
Connection:keep-alive
Cookie:express:sess=eyJ1c2VySWQiOiI1MzgxYTdjMDA0ZmIwMmIxMGI1NTdlZTMifQ==; express:sess.sig=lm-kq5ludtkWdRcFcVxNBL0BdT0
Host:localhost:9000
If-None-Match:W/"v9r1H7w4HiaXvycJ9FJ7lg=="
Referer:http://localhost:9000/
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Response Headersview source
access-control-allow-headers:Content-Type, X-API-KEY
access-control-allow-methods:GET, POST, DELETE, PUT
access-control-allow-origin:*
cache-control:public, max-age=300
connection:close
date:Sat, 03 Jan 2015 08:47:29 GMT
expires:Sat, 03 Jan 2015 08:52:29 GMT
etag:W/"v9r1H7w4HiaXvycJ9FJ7lg=="
x-powered-by:Express
However, I see my backend gets the request each and every time.
I have tried it with developers area open and closed and with "cache" on and off.
Nothing seems to actually cache the request
What am I doing wrong?
I'm trying to do a simple HTTP POST on the following website:
https://oktap.tax.ok.gov/oktap/web/_/
(click on "Permits" in the bottom left hand side)
I simply want to post a number and get the results from the page returned. Looking at the page with chrome's web developer tools it looks like the POST goes to both
https://oktap.tax.ok.gov/oktap/web/_/Recalc
https://oktap.tax.ok.gov/oktap/web/_/EventOccurred
I'm not sure if it's one or the other, it looks like EventOccured takes a couple more parameters. However when I post to either one of them with the following code:
#!/usr/bin/env bash
wget --post-data="D0IHwpHb__0_0_Ful0QW=5&VIEW__=VS_PermitSearch&LASTFOCUSFIELD__=D0IHwpHb__0_0_Ful0QW&DOC_MODAL_ID__=0&EVENT__=D0IHwpHb__0_0_Ful0QW&DOC_ACTION__=false&TYPE__=1&CLOSECONFIRMED__=false&FAST_VERLAST__=9.CvUZWPROHiWR-EO6d9UAeHYv4m81" \
-U "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547 Safari/537.36" \
https://oktap.tax.ok.gov/oktap/web/_/EventOccurred
First I get 307 Temporary Redirect and then ERROR 405: Method Not Allowed.
I don't see how the a post is not allowed, when it's clearly being made from the browser just fine. Any Help?
Here's the headers:
Request URL:https://oktap.tax.ok.gov/oktap/web/_/Recalc
Request Method:POST
Status Code:200 OK
Request Headersview source
Accept:application/json, text/javascript, */*; q=0.01
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Content-Length:146
Content-Type:application/x-www-form-urlencoded
Cookie:wdc-session=w0srLHI6Tz9tDLtEDo0n33PNuXSFexxysEHBa9v5dtjXBt/X4cKb9zKdxoVrtyDKseewwZMbU41vn3DLmyf0QUUjtKwXdmEhHtS69aZf94Y26cqd95rsiCKg06SQVIm5p63me/C2chBBapoABa1lJ8lf4F3MbBIiBAnCnbKlgVfXtsjpijt9i2PMILjlAalr
Host:oktap.tax.ok.gov
Origin:https://oktap.tax.ok.gov
Referer:https://oktap.tax.ok.gov/oktap/web/_/
User-Agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/31.0.1650.4 Chrome/31.0.1650.4 Safari/537.36
X-Requested-With:XMLHttpRequest
Form Dataview sourceview URL encoded
D0IHwpHb__0_0_Ful0QW:5
VIEW__:VS_PermitSearch
LASTFOCUSFIELD__:D0IHwpHb__0_0_Ful0QW
DOC_MODAL_ID__:0
FAST_VERLAST__:3.2sMmdbnwgvAQF41H3c_2XHozyeA1
Response Headersview source
Cache-Control:no-cache, no-store, max-age=0, must-revalidate
Content-Encoding:gzip
Content-Language:en, en-US
Content-Length:318
Content-Type:application/json; charset=utf-8
Date:Thu, 03 Oct 2013 19:52:52 GMT
Expires:Fri, 01 Jan 1990 00:00:00 GMT
Pragma:no-cache
Server:Microsoft-HTTPAPI/2.0
Set-Cookie:wdc-session=w0srLHI6Tz9tDLtEDo0n33PNuXSFexxysEHBa9v5dtjXBt/X4cKb9zKdxoVrtyDKseewwZMbU41vn3DLmyf0QUUjtKwXdmEhHtS69aZf94Y26cqd95rsiCKg06SQVIm5p63me/C2chBBapoABa1lJ8lf4F3MbBIiBAnCnbKlgVfXtsjpijt9i2PMILjlAalr; path=/oktap/web/; HttpOnly; Secure;
X-Frame-Options:DENY
and
Request URL:https://oktap.tax.ok.gov/oktap/web/_/EventOccurred
Request Method:POST
Status Code:200 OK
Request Headersview source
Accept:application/json, text/javascript, */*; q=0.01
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Content-Length:226
Content-Type:application/x-www-form-urlencoded
Cookie:wdc-session=w0srLHI6Tz9tDLtEDo0n33PNuXSFexxysEHBa9v5dtjXBt/X4cKb9zKdxoVrtyDKseewwZMbU41vn3DLmyf0QUUjtKwXdmEhHtS69aZf94Y26cqd95rsiCKg06SQVIm5p63me/C2chBBapoABa1lJ8lf4F3MbBIiBAnCnbKlgVfXtsjpijt9i2PMILjlAalr
Host:oktap.tax.ok.gov
Origin:https://oktap.tax.ok.gov
Referer:https://oktap.tax.ok.gov/oktap/web/_/
User-Agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/31.0.1650.4 Chrome/31.0.1650.4 Safari/537.36
X-Requested-With:XMLHttpRequest
Form Dataview sourceview URL encoded
D0IHwpHb__0_0_Ful0QW:5
VIEW__:VS_PermitSearch
LASTFOCUSFIELD__:D0IHwpHb__0_0_Ful0QW
DOC_MODAL_ID__:0
EVENT__:D0IHwpHb__0_0_Ful0QW
DOC_ACTION__:false
TYPE__:1
CLOSECONFIRMED__:false
FAST_VERLAST__:4.Ol_i_B9mDsWsP0Mg0e02_y7OZjM1
Response Headersview source
Cache-Control:no-cache, no-store, max-age=0, must-revalidate
Content-Encoding:gzip
Content-Language:en, en-US
Content-Length:3711
Content-Type:application/json; charset=utf-8
Date:Thu, 03 Oct 2013 19:52:52 GMT
Expires:Fri, 01 Jan 1990 00:00:00 GMT
Pragma:no-cache
Server:Microsoft-HTTPAPI/2.0
Set-Cookie:wdc-session=w0srLHI6Tz9tDLtEDo0n33PNuXSFexxysEHBa9v5dtjXBt/X4cKb9zKdxoVrtyDKseewwZMbU41vn3DLmyf0QUUjtKwXdmEhHtS69aZf94Y26cqd95rsiCKg06SQVIm5p63me/C2chBBapoABa1lJ8lf4F3MbBIiBAnCnbKlgVfXtsjpijt9i2PMILjlAalr; path=/oktap/web/; HttpOnly; Secure;
X-Frame-Options:DENY
As a developer for that company, I would not recommend looking up permits that way. For $150 per year you can get a file with this information.
Contact the OTC. http://www.tax.ok.gov/rules/rule6507.pdf - 710:65-9-6. Subscription to sales tax permit list
I have inherited a large application and whenever an exception occurs I get a screen of gibberish in Chrome:
However in IE it shows the yellow screen of death as expected:
I can't figure out why this would even happen. Could it be an encoding problem?
Edit - Here are the request and response headers:
Request:
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Cookie:.ASPXAUTH=5D3E8316B9AF0... [cut for brevity]
Host:localhost:81
Referer: **************** [intentionally hidden]
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.96 Safari/537.4
Response:
Cache-Control:private
Content-Length:6193
Content-Type:text/html; charset=utf-8
Date:Wed, 07 Nov 2012 16:42:15 GMT
Server:Microsoft-IIS/7.5
X-AspNet-Version:4.0.30319
X-Powered-By:ASP.NET
Try debugging this case with the Chrome Developer Tools (menu Tools -> Developer Tools). Switch to the Network tab and reload the page. Now click on the file name in the left column and check Headers -> Response Headers -> content-type for the value text/html as well as content-encoding for gzip. Maybe the response is compressed but this is not correctly declared in the http headers.
Also look into the Response tab. Is the content there a readable html document?
I am using NetStream, NetConnection and Video object to play an mp4 file which is hosted over a web server using http.
The mp4 file URL is for example: http://xx.xx.xx.xx/file.mp4
This is an AIR application and the relevant code is pasted below:
var url:String = <some http url>;
connect_nc = new NetConnection();
connect_nc.connect(null);
stream_ns = new NetStream(connect_nc);
var ns_object:Object = new Object();
ns_object.onPlayStatus = ns_onPlayStatus;
stream_ns.client = ns_object;
videoMP4.attachNetStream(stream_ns);
stream_ns.bufferTime = 1.0 // 1 sec
stream_ns.addEventListener(NetStatusEvent.NET_STATUS, onNetStatusEventHandler);
stream_ns.play(url);
This code works when run on MAC OS X. But it does not work when run on Windows XP. I get the error:
NetStream.Play.StreamNotFound
I also tried playing the URL using VLC player on the same windows XP host. The URL is valid because VLC can play it.
In my particular case, the http URL is hosted by WMP 12 (window media player 12) on Win 7 machine where I am using the media sharing feature of WMP 12.
After further looking into http traffic on wireshark, here is what i found.
After running wireshark on the host running the adobe AIR application, it seems that it is getting a HTTP 406 response from
the server being run by WMP 12.
GET /WMPNSSv4/63903908/1_ezVGREUzQTA4LTdDQzQtNDJFMy1CNDVDLUZEMjA4MDE5OUM4Q30uMC44.mp4 HTTP/1.1
Host: 192.168.0.102:10243
User-Agent: Mozilla/5.0 (Windows; U; en) AppleWebKit/526.9+ (KHTML, like Gecko) AdobeAIR/1.5
Referer: app:/clicker.swf
x-flash-version: 10,0,12,36
Connection: Keep-Alive
Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, text/plain;q=0.8, text/css, image/png, image/jpeg, image/gif;q=0.8, application/x-shockwave-flash, video/mp4;q=0.9, flv-application/octet-stream;q=0.8, video/x-flv;q=0.7, audio/mp4, application/futuresplash, */*;q=0.5
Response:
HTTP/1.1 406 Not Acceptable
Last-Modified: Mon, 19 Oct 2009 23:21:14 GMT
Server: Microsoft-HTTPAPI/2.0
Accept-Ranges: bytes
TransferMode.DLNA.ORG: Streaming
Date: Tue, 12 Jan 2010 22:52:48 GMT
Connection: close
Content-Length: 0
On MAC:
It receives 200 OK response though, and that is why the video streaming works.
GET /WMPNSSv4/63903908/1_ezVGREUzQTA4LTdDQzQtNDJFMy1CNDVDLUZEMjA4MDE5OUM4Q30uMC44.m p4 HTTP/1.1
Host: 192.168.0.102:10243
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/526.9+ (KHTML, like Gecko) AdobeAIR/1.5.3
Referer: app:/clicker.swf
X-Flash-Version: 10,0,42,34
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: keep-alive
Response:
HTTP/1.1 200 OK
Content-Length: 1524867
Content-Type: video/mp4
Last-Modified: Mon, 19 Oct 2009 23:21:14 GMT
Server: Microsoft-HTTPAPI/2.0
Accept-Ranges: bytes
TransferMode.DLNA.ORG: Streaming
Date: Tue, 12 Jan 2010 22:56:20 GMT
The difference that I can see in the HTTP requests between the Windows XP and MAC version is the Accept: Header. Is the Accept: header value wrong for Windows case because of which WMP 12 rejects
the http request.
If i run the adobe AIR application on Win 7 host, i see the same failure.
Am I using the NetStream object incorrectly or it is a bug in WMP 12 code not being able to parse
the header properly or it is a flex bug where it is generating an incorrect accept: header?
I believe WMP 12 incorrectly handles 'Accept' header in a request. If it contains 'q' (quality) parameter, then WMP ignores this mime-type. And if there are no other suitable mime-types for WMP, it will respond with 406 Not Acceptable error.
I encountered this issues when was trying to display DLNA image in Chrome browser.
I used curl utility to send requests with different headers to figure out what goes wrong.
Request that results in 406 Not Acceptable error:
curl -v -o file.jpg -H "Accept: text/html,*/*,q=0.8" "http://127.0.0.1:10243/WMPNSSv4/3065481158/0_e0I5MzA1MTRELUYwMEEtNEQwRC1CQzg4LTg3NEI5QjQ4MDYyM30uMC5C.jpg"
GET /WMPNSSv4/3065481158/0_e0I5MzA1MTRELUYwMEEtNEQwRC1CQzg4LTg3NEI5QjQ4MDYyM30uMC5C.jpg HTTP/1.1
User-Agent: curl/7.31.0
Host: 127.0.0.1:10243
Accept: text/html,*/*;q=0.8
HTTP/1.1 406 Not Acceptable
Last-Modified: Tue, 21 May 2013 21:01:09 GMT
Server: Microsoft-HTTPAPI/2.0
Accept-Ranges: bytes
TransferMode.DLNA.ORG: Interactive
Date: Fri, 30 Aug 2013 09:10:32 GMT
Connection: close
Content-Length: 0
Successful request:
curl -v -o file.jpg -H "Accept: text/html,*/*" "http://127.0.0.1:10243/WMPNSSv4/3065481158/0_e0I5MzA1MTRELUYwMEEtNEQwRC1CQzg4LTg3NEI5QjQ4MDYyM30uMC5C.jpg"
GET /WMPNSSv4/3065481158/0_e0I5MzA1MTRELUYwMEEtNEQwRC1CQzg4LTg3NEI5QjQ4MDYyM30uMC5C.jpg HTTP/1.1
User-Agent: curl/7.31.0
Host: 127.0.0.1:10243
Accept: text/html,*/*
HTTP/1.1 200 OK
Content-Length: 2394679
Content-Type: image/jpeg
Last-Modified: Tue, 21 May 2013 21:01:09 GMT
Server: Microsoft-HTTPAPI/2.0
Accept-Ranges: bytes
TransferMode.DLNA.ORG: Interactive
Date: Fri, 30 Aug 2013 09:10:40 GMT