does anyone know how to serve a web bundle so that it loads, rather than just downloading as a file?
Some disambiguation: There is a format called WebPackage (not to be confused with webpack), also called a Web Bundle. Files typically have the .wbn suffix. It contains html and js files and can be used to view websites offline. Useful for e.g. archiving websites or making websites that work well with intermittent network access. Download the file once, and you have all the assets you need for at last basic operation of the site.
The standard on how to serve a .wbn file is here:
https://wicg.github.io/webpackage/draft-yasskin-wpack-bundled-exchanges.html
However when I add the required headers in the web server, the .wbn file is just downloaded. If I drag the downloaded file onto my browser (google-chrome), the file is displayed as the website it contains, so unless there is some very subtle bug in there I believe that the format of the bundle is OK.
Here is a sample request:
Request URL: http://localhost/bundle/www-signed.wbn
Request Method: GET
Status Code: 200 OK
Remote Address: [::1]:80
Referrer Policy: strict-origin-when-cross-origin
and the server response:
Accept-Ranges: bytes
Connection: keep-alive
Content-Length: 4300
Content-Type: application/webbundle <-- Required by the standard
Date: Thu, 02 Sep 2021 12:00:24 GMT
ETag: "612ef7cb-10cc"
Last-Modified: Wed, 01 Sep 2021 03:47:23 GMT
Server: nginx/1.18.0 (Ubuntu)
X-Content-Type-Options: nosniff <-- required by the standard
If anyone has this working on a website or knows how to do it, I would love to have a look.
I had the same problem that the wbn file was just downloaded instead of executed.
I had to enable the web bundles feature even though my chrome version is 96+
Related
I use Xampp control panel to host an Apache server. I'm testing how to run mhtml files on a server. So far it only shows me raw text when visiting it on server side. I looked around on how to make it work but the solutions I got (for example, adding "AddType message/rfc822 .mhtml .mht" in http conf file) just proceeds to download the file instead of reading it.
Here's a sample of the initial block of the mhtml file:
From: <Saved by Blink>
Snapshot-Content-Location: https://www.instagram.com/jo0sef/
Subject: =?utf-8?Q?Yousef=20AlSudais=20=D9=8A=D9=88=D8=B3=D9=81=20=D8=A7=D9=84=D8?=
=?utf-8?Q?=B3=D8=AF=D9=8A=D8=B3=20(#jo0sef)=20=E2=80=A2=20Instagram=20pho?=
=?utf-8?Q?tos=20and=20videos?=
Date: Tue, 16 Feb 2021 08:18:55 -0000
MIME-Version: 1.0
Content-Type: multipart/related;
type="text/html";
boundary="----MultipartBoundary--c1Osf7aCebmaZjjAXk0gfl7cuYp300joTDYRFPKyLF----"
------MultipartBoundary--c1Osf7aCebmaZjjAXk0gfl7cuYp300joTDYRFPKyLF----
Content-Type: text/html
Content-ID: <frame-AD05338F6D10E72FA62E6C2E3D66903E#mhtml.blink>
Content-Transfer-Encoding: quoted-printable
Content-Location: https://www.instagram.com/jo0sef/
I'm reading it in Webpack docs:
The way it works has a pitfall: if we don’t change filenames of our resources when deploying a new version, browser might think it hasn’t been updated and client will get a cached version of it.
I'm curious, is it mandatory to use this mechanism with ugly file names main.55e783391098c2496a8f.js for assets in order to inform a browser that an asset file has changed?
Can it be controlled by HTTP headers only? There are multiple HTTP headers in the standard to control how browser caches assets, like:
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
Date: Wed, 24 Aug 2020 18:32:02 GMT
Last-Modified: Tue, 15 Nov 2024 12:45:26 GMT
ETag: x234dff
max-age: 12345
So can I use those headers alone? Or do I still have to bother about hash parts in file names main.55e783391098c2496a8f.js?
When user agent opens a page it must always get correct version of a source code. You have two options to achieve this:
Set Cache-Control, Expires and strong validator (ETag) response headers . This way you instruct user agent to perform relatively lightweight conditional request on each page load
Embed version in source code file URL and set Cache-Control and Expires response headers. This way you instruct user agent to cache source code with particural version forever
For more information check HTTP Caching article by Ilya Grigorik, HTTP conditional requests MDN page and this StackOverflow answer about resource revalidation.
I have an Apache server running a website with a symfony 2 login form, two weeks ago some of the users got their computers updated to windows 10, since then, sometimes when they click the login button Chrome downloads this file called "login" i attached instead showing it:
0
HTTP/1.1 200 OK
Date: Thu, 24 Nov 2016 14:41:00 GMT
Server: Apache
X-Powered-By: PHP/5.4.22
Cache-Control: no-cache
X-Debug-Token: 7216b3
Vary: Accept-Encoding
Content-Encoding: gzip
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
794
‹ ´Y{oÛ8ÿÛù\]‹Ú#$YNÓ¼ä²n»W`swhZÜE!ÐÒØbB‘*I9I/ýP‡ûûÅnHJ~dSl³ˆƒÆó›g8ÃiúS!ss[)MÅOwRûE8óq : ºÎóò«q`TÁé!i ´8Ýé¥Jò’*
f4f$¶+†§ï&oÈ+#Ñ4öS• Œƒt®Xm˜É¥0 (¸·‹6¦”jsÁ¿§4¦áKÃãàßádzp"«š6å°FòîÍ8žü:rŸ ?…á'6#Üà$9úŒS½ÔËD´ÊÇE?Žck–}]²*šK9çË¢\V±^ˆ
#®ü–èR§iìþ'›}Cy~ä\NrQCÎf,'稆&nǺÚ×µTfM‹kV˜r\À‚åºÁ.a‚Fy¨sÊaœì’ŠÞ°ª©º «(q¼[½ìqãi‰/é‚úYkóÞ‚*2UòZƒêõzc”cÁæÔH58u6GN6·½‡9Üàθ&
%Yq÷3§ùÕÏ ÔíÝ»7^Ó»¿Ë+FïØ?û´¸+¥€;YîþQ£[ó>n¹Cƒ¸ÃfÚÓYf”k°lÖoyF5yÙ_—`0 ÿÁ=½%’Zµ”=Zo(û¯L£Aõ.iì’Y#rë{}$'èÃX²1ý]öãû_§Tí’áà„|Ûõr\GEVÛúǾwÍD!¯#4©äüƒìwOómÇÿº]^K.íù1±v‚“Χí]µ·kTHq[É·l¬ËDEë/
hCkv·¸ùmuiŠçÞ4ÓQ1œ
þ|49˜?ß{-÷ãfDËk„éuèV36oÙ´?© Ø
>¢çTÐ9(9®†ç´^
^;\ùAJ®ñÏ3f]¼å (Ì:6ëÔ8Á‚Ïk²ÎÅE††õbÚÅgNôìUÀµ!6¹¸ðå pSÊ™¸"¥‚Ù8ˆi]gDQ]Öq®u\L‹W‡Ù”jÈ’§‚õ(qc|hs‹ìKTÂ_?
L+ú•5U6Ú6§·è³ÙÞ WtÙË-À_¢÷ªÛ°aÙþÐφ»Ì^mMð¨j¸a€ÙÀdÛ´OhðbªY~*ÄËLŠìp§í4eGÛ³ØÃê,nAM•É’$&!ÞˆŒKýÈ#Þù#NÃdïÕèððOsXÞMo1«âÕë3¾«c[O……ŽÉC쎙Ux5Æ7¡ŸkÅ›y”?ÚRf…‚¢slòÒ…µÂŠ¥ª¥†"XÓocST‹yð;‚£›ƒÑwQC·ì°'e‹ž$/oð÷ûø톇ÖÊ$þ«‰Omuå~6Ê»S¾Ôñè°íÑ.ô’è(â1_¶§L¨›Ö’Ï#Ñ1°-ƒ¦…1`É¡ÀÜ°5üßÝL/·Ãkã²Ýß\b¡
sÆvðÝõwðÔà•¬°6Ãç€)CûrÓ˜¶ÃÂöW¬ß1E<1ƒ‚x+Vö6=<1x—Ø’-rÔ–`É–âQ¬L·Çè÷\ª©¼É’'^Ÿ—÷mÖÔ•”¦ôo£§¿S—ŒF¡{Y±¯Ô>ÒB¯"Ö˜O~8KŽ{¡{rcÂ
Ñ’M%ôÓ߸Kf/C+6Ãî!ªŸþÒ]²Ûu3ÅàoôŸºuî5´¼ÛGg<“úR+Œ &æVû'>óïµR~óž>-ê_Ñ!ø”æWcä½÷øø2}M
Ý`âʱÇÈ>Ň˜S¸±e‹ÁGªæÎï,ón(UT1±©+8„SÛ€J°ˆ½Š’(ÙÛÐÑæ÷¸±DÔ1l°øQ›¡¨øº/¤ŠWy½æÍœ Ôa™ßãõ°Š¬ #ß;´®cñH1|º‰»tsõGšY;«6MŽX &îŠ×lÑ÷Ý¢gýáµÄ›ïÅÀ–ò}×ÅÁ“d–ðøjŒg/ví<‡™9&ýg}ßåD®‡`!¹åüë_~uµ‘õq l^šïRÿ]FrÛ:²]¤o¨Ô³~!óÆZg) Åm½‡å”ê(°%tÿwÚ#î{À(–…ýX94uûvo:•Åíi/-Ø‚°bt$çTc©ž·`®•˜Î0›êD»–Ž0sMå€T`J‰hht߃ì¥õ&`;˪yë'î9¤-ŒôU?åfØ^s÷–KãzYí[q[<tVmðòA)©s©„\9G'´6ËXŒèc2Œ : ºû¬¦b
Ç>=Hû21“Kú—ÝÄ:Ë ©¨B]CeÏò˜´€h_ëp’b~:A»ÈµÝ-ï·ÿ wúe¯ª²T«îz[)§SàÍ‚iP¶wœ~Ô
UL§±[>M§*^R0Q7둸ó\·íçl5ÑêíÎQdAyc{ó÷mþ°d5\K…¾1‘ïE
¿ý—þ±tK2'ájÔJ¸šxHÂ
¹º6àCÎåØNcðL—žù‰î
n³ 3N|¬%©Jc¿¾¤÷lÒØú½}çúÓÂèqac£ÈýËÿ ÿÿ
a
°•Tüq
0
Only computers using google Chrome that have been updated to windows 10 have this issue. Other computers using Chrome or using Internet Explorer from the same computer works fine.
I have tried to change the response headers of the Content-Type to text/html using the ModHeader extension but the Chrome shows the same content of the file without interpreting it.
I have tried with older versions of Chrome with the same result.
Also I disabled the Apache compression but still sometimes Chrome downloads the page.
The user have disabled the antivirus but the issue keeps the same.
Browsing a similar version of the application hosted in another server works fine.
I don't know if the issue is related to the clients or the server.
Edit:
It looks like the computers have FortiNet installed and it could be breaking the network packages.
I cant access a specific filetype on my customer server (production).
Here are the results with cURL:
curl "http://domain.tld/fonts/glyphicons-halflings-regular.eot" -I
HTTP/1.1 200 OK
Date: Tue, 28 Jul 2015 12:06:23 GMT
Server: Apache/2.2.15 (Red Hat)
Last-Modified: Tue, 19 May 2015 15:32:20 GMT
ETag: "14023-4f42-516710421e900"
Accept-Ranges: bytes
Content-Length: 20290
Connection: close
Content-Type: application/vnd.ms-fontobject
The file is here.
But when I try to get the file content:
curl "http://domain.tld/fonts/glyphicons-halflings-regular.eot"
curl: (56) Recv failure: Connection was reset
I can't (yet) access the customer server, so I'm trying to guess what's wrong here.
What is working so far:
curl "https://domain.tld/fonts/glyphicons-halflings-regular.eot" --insecure
It is working in HTTPS, even if there is no certificate (which is why I use --insecure). I get the file content.
The customer can get the file if he accesses the file from a local URL.
I can access all other files on the server, even in the fonts directory.
I can't access all .eot files, even in other directories.
So I think it is one of those 2 problems:
- Apache configuration / .htaccess problem.
- Proxy / reverse proxy problem.
What do you think about it?
What kind of other test should I do?
What information should I ask to the customer?
Thanks.
Ok, here is the cause:
The customer firewall blocks .eot file content.
A vulnerability in Embedded Web Fonts Could Allow Remote Code Execution.
http://www.checkpoint.com/defense/advisories/public/2006/cpai-2006-010.html
As the .eot files are used by IE8 and lower, and those browser versions are not required by the customer, I've simply removed all references to .eot files.
Another solution would be to ask for the customer firewall admins to add an exception, as the severity is low.
This problem seems related to our server configuration.
I have a video that I want to play with HTML5 video on a website. I use video.js for playback.
The problem is: the video works on my localhost, but it does not work on the production server.
I tried two different servers and they work flawlessly.
I Really need it to work on this specific server (it has a load balancer and more punch to handle the load we are expecting)
I am stumped; I don't know why it does not work on this server, I expect it to be an apache config issue because it works on the other servers.
I looked at the response headers, they are identical (see below). The movie encoding should be allright as well as they are playing on mobile devices on the test servers.
TEST SERVER (works):
HTTP/1.1 200 OK
Date: Tue, 03 Sep 2013 08:16:29 GMT
Server: Apache
Last-Modified: Mon, 26 Aug 2013 09:05:00 GMT
ETag: "baa32-4ceeb0-4e4d60d0e0700"
Accept-Ranges: bytes
Content-Length: 5041840
Cache-Control: public
Content-Type: video/mp4
PRODUCTION SERVER (does not work):
HTTP/1.1 200 OK
Date: Tue, 03 Sep 2013 08:28:07 GMT
Server: Apache
Last-Modified: Mon, 02 Sep 2013 12:18:39 GMT
ETag: "956c0-4ceeb0-4e565927d85c0"
Accept-Ranges: bytes
Content-Length: 5041840
Cache-Control: public
Content-Type: video/mp4
Can anyone give any leads what might be happening here?
Any leads are greatly appreciated.
I found the cause of the problem.
It was related to Request-Range headers.
(See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.2 for more information about Request-Range headers)
We had Request-Range headers disabled for security reasons. It turns out that this breaks video playing functionality for IOS devices (desktop and android browsers still worked - tested Firefox and Chrome as well as Android - Chrome)
Allowing Request-Range solved the issue.