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.
Related
Some websites provide pdf files for viewing but I can't download such pdf files with wget.
Calling the website in question from my browser views the pdf:
https://www.lokalmatador.de/epaper/ausgabe/gemeinderundschau-muehlhausen-14-2021/
But using the following code I only get a pdf file with 0 lenght.
wget --content-disposition -nd https://www.lokalmatador.de/epaper/ausgabe/gemeinderundschau-muehlhausen-14-2021/
I tried some combinations with saving and loading cookies and referer but nothing works.
At this point I'm just curious what is happening and why wget is not fetching anything except maybe an empty index.html.
When I was looking at server response, it was saying the content length was 0.
--2021-04-17 14:59:35-- https://www.lokalmatador.de/epaper/ausgabe/gemeinderundschau-muehlhausen-14-2021/
Resolving www.lokalmatador.de (www.lokalmatador.de)... 37.202.6.70
Connecting to www.lokalmatador.de (www.lokalmatador.de)|37.202.6.70|:443... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Sat, 17 Apr 2021 13:59:36 GMT
Server: Apache
Set-Cookie: fe_typo_user=477e8a1d2b3dd74bc5b6b408a6d74edd; expires=Mon, 17-May-2021 13:59:36 GMT; Max-Age=2592000; path=/; domain=.lokalmatador.de; httponly; samesite=lax
Upgrade: h2,h2c
Connection: Upgrade, Keep-Alive
Content-Length: Array
Cache-Control: max-age=2592000
Expires: Mon, 17 May 2021 13:59:36 GMT
X-UA-Compatible: IE=edge
X-Content-Type-Options: nosniff
Keep-Alive: timeout=5, max=100
Content-Type: application/pdf
Length: 0 [application/pdf]
Remote file exists but does not contain any link -- not retrieving.
So looked at the manual:
https://www.gnu.org/software/wget/manual/html_node/HTTP-Options.html
And there is a command just exactly for this:
‘--ignore-length’
Unfortunately, some HTTP servers (CGI programs, to be more precise) send out bogus Content-Length headers, which makes Wget go wild, as it thinks not all the document was retrieved. You can spot this syndrome if Wget retries getting the same document again and again, each time claiming that the (otherwise normal) connection has closed on the very same byte.
With this option, Wget will ignore the Content-Length header—as if it never existed.
Then the wget command started working as expected:
wget --ignore-length -O epaper.pdf https://www.lokalmatador.de/epaper/ausgabe/gemeinderundschau-muehlhausen-14-2021
Here is output which I'm seeing with the ignore length:
--2021-04-17 14:56:19-- https://www.lokalmatador.de/epaper/ausgabe/gemeinderundschau-muehlhausen-14-2021
Resolving www.lokalmatador.de (www.lokalmatador.de)... 37.202.6.70
Connecting to www.lokalmatador.de (www.lokalmatador.de)|37.202.6.70|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: ignored [application/pdf]
Saving to: ‘epaper.pdf’
epaper.pdf [ <=> ] 4.39M 1.23MB/s in 3.6s
2021-04-17 14:56:23 (1.21 MB/s) - ‘epaper.pdf’ saved [4601842]
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.
My website is visible (http://www.nowis-informatique.fr) but when I try a :
curl -I http://www.nowis-informatique.fr/assets/front/img/slider/2/-tincelles-de-couleurs_480x480.png
My header is :
HTTP/1.1 404 Not Found
Date: Fri, 16 Jan 2015 13:14:41 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=iso-8859-1
But when i try with arg -4 on curl, it's work.
Reallity problem :
When sharing a facebook page (if I copy the URL in a new Facebook status, for example), the image and description generated by Facebook is not at all that of my site, but homepage of my server.
example: www.nowis-informatique.fr
Accessible without worries from my browser. When I put the URL into a facebook status he me out of my server page "87.106.242.7" ...
On this server I have several field and it does the same for them. I want to say that everything worked on 09.22.2014, the date of my last Facebook publication.
I looked on the developers.facebook.com/tools/debug/ software The return code is 206, and the information is that of my "87.106.242.7" obviously ...
I do not know how strictly fix the problem ...
Thank you all
Apache v2.2
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.
I have lot of small images (of sizes ~3kb or so) and lot of css and js files. After the first request tey are getting cached on the browser, but when I reload the page the browser is trying to check the freshness of the cached content (by setting the If-Modified-Since etc) and gets the response 304 not modified. Each of this validation request seriously increase the page load time (say 20 time 300ms).
How can I cancel this cache freshness check with the server from the browser? How can instruct the browser to use local cached files/images for certain time (say 1 hour) without re-validating or checking the freshness of the local cache with the remote server for every reload with that time period?
sample small image fetch header details below [using rails 3.1, on heroku]:
Response Headers
HTTP/1.1 304 Not Modified
Server: nginx/0.7.67
Date: Thu, 10 Nov 2011 17:53:33 GMT
Connection: keep-alive
Via: 1.1 varnish
X-Varnish: 1968827848
Last-Modified: Tue, 08 Nov 2011 07:36:04 GMT
Cache-Control: public, max-age=31536000
Etag: "5bda917d22f8a144c293f3f19723dbc6"
Request Headers
GET /assets/icons/flash_close_button-5bda917d22f8a144c293f3f19723dbc6.png HTTP/1.1
Host: ???.heroku.com
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.1) Gecko/20100101 Firefox/6.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://???.heroku.com/
Cookie: ???
If-Modified-Since: Tue, 08 Nov 2011 07:36:04 GMT
If-None-Match: "5bda917d22f8a144c293f3f19723dbc6"
Cache-Control: max-age=0
This line:
Cache-Control: public, max-age=31536000
is telling the browser to not ask for updates for a long time, and store the files in a publicly accessible cache (which hear means public to the local machine - not the general public). Your browser should therefore not really be re-checking those files. Have you tried another browser to verify this behaviour exists elsewhere?
Saying all of this though, considering that your files are coming from the varnish cache and not your dyno, and are being returned as HTTP 304, 300ms for 20 files sounds like a very long time. However, This should be barely perceptible to the user.