Chrome sometimes downloads html instead showing it - apache

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.

Related

Why is my Rest API not working with my ip?

There is json i need to access with a GET request, it has no restrictions, my friends can access it from their location.
However, from my device (tried on Chrome, Firefox, VS Code, Edge), and even from my phone, both have a different IP, I cannot access it.
Transfer-Encoding: chunked
Content-Type: application/json; charset=utf-8
X-Xss-Protection: 0
X-Content-Type-Options: nosniff
X-Permitted-Cross-Domain-Policies: none
Date: Fri, 07 Jan 2022 08:46:09 GMT
This is the output from an online request testing app, and it works.
Is there anything in this output that can give me a hint on what to change to make it accessible from any device?
Where is the JSON located? If it is at your friends, try port forwarding at his place. If it isn't, we will need to see your code and we will need more context. Internet access can get complicated.

How to serve a wbn (WebPackage/WebBundle) file from a web server?

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+

Railo 4.1.1 - How to Remove "exception-message" header

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.

Chromium Loading Mod_Rewrite'd Pages Twice

When I Mod_Rewrite a page, Chromium will load the page twice. Other browsers like Firefox only load it once. I have seen a tun of posts saying Chromium has trouble with empty GET requests, but that doesn't seem to apply to me as the only thing I'm returning is a basic static HTML page with only the count of requests in it.
<!DOCTYPE html><html><head><title>TITLE</title></head><body>3</body></html>
The 3 indicates the count of total page loads (and is pretty much the only dynamic value in this)
When I load pages in Firefox or using wget in the terminal it returns 1, 2, 3, 4, 5... as it should, while Chromium returns 1, 3, 5, 7, 9....
I don't really get how Chromium is supposed to know when a page is Mod_Rewritten. (There should be no difference in output should there? )
Also in case it matters, these are the HTTP response headers.
HTTP/1.1 200 OK
Date: Sun, 13 Oct 2013 17:53:50 GMT
Server: Apache/2.2.22 (Ubuntu)
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 76
Keep-Alive: timeout=5, max=86
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
After searching through the access log I saw Chromium was also trying to load favicon.ico which obviously got rewritten too and thus caused a second page load.

mp4 video not playing on mobile devices

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.