Firefox 3.5 er verdens største browser

I hvert fald hvis man skal tro på netmåleren Statcounters seneste tal. Bedømt på samlede versionsnumre fører Internet Explorer dog stadig. I Danmark er den røde ræv langt bagefter konkurrenten.

Der findes løgn, forbandet løgn og browserstatistik - og ifølge den seneste melding fra tællemaskinen Statcounter er Firefox nu verdens mest anvendte browser.

Med 21,9 procent tager open source-browseren føringen over Internet Explorer 7 på 21,2, forfulgt af samme program i version 8 med 20,3 procent af brugerne. På tredjepladsen ligger IE 6 med 13,9 procent, så samlet set fører Microsofts browser stadig stort.

Statcounters tal bygger på fire milliarder sidevisninger om måneden. Webstatistik-firmaet overvåger webtrafik for to millioner kundesites, hvoraf en halv million befinder sig i Europa.

Statcounters tal for Europa giver Firefox endnu mere luft under vingerne. Her får version 3.5 tilslutning fra 28,4 procent af de europæiske brugere. Nøjagtig samme tal kommer det franske analysefirma AT Internet Studies frem til, baseret på tal fra september.

Herhjemme ligger Firefox 3.5 dog langt bagefter Internet Explorer. Ifølge FDIM's seneste tal, som er opgjort i oktober, har browseren kun 11 procent af de danske browserbrugere.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (17)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jesper Gaardbo Langhoff

GET /brumleby/Pletskud6.html HTTP/1.1
Host: homepage.mac.com

HTTP/1.1 200 OK
Date: Mon, 21 Dec 2009 14:54:25 GMT
Content-Length: 17495
Content-Type: application/octet-stream
Cache-Control: max-age=60, must-revalidate
Server: AppleIDiskServer-1F3014
x-responding-server: hpng004
Set-Cookie: mmr=nk11r10; Domain=homepage.mac.com; Path=/brumleby
Set-Cookie: mmr=nk11r10; Domain=homepage.mac.com; Path=/brumleby
X-dmUser: brumleby
ETag: "u-1g3s18hn-4bnp-pa6yk1hmb-2589juze7s0"
Last-Modified: Sun, 20 Dec 2009 21:50:25 GMT
Via: 1.1 hpcache008 (NetCache NetApp/6.0.5P2D2)'

Firefox gør da som den skal, når du sender "Content-Type: application/octet-stream" ud til den.

Dårlig HTTP server?

  • 0
  • 0
Benny Allan Andersen

Du ved åbenbart noget om det.
Hvis jeg sætter siden ind på min iDisk hos Mac.com ved, på min mac, at kalde et icon ned på mit skrivebord, hvorefter jeg kan bruge det som en hvilken som helst folder, giver det ingen problemer at se den med Firefox.
Se eksempelvis: http://homepage.mac.com/brumleby/Omegn6.html
som er skrevet på nøjagtigt samme facon som ovenstående Pletskud 6.html
Men har jeg brugt min browser til at uploade html-siden, og det er ligegyldigt hvilken browser, og gået ind på min iDisk via http, téer Firefox sig underligt, og vil downloade siden; men ikke vise den. De andre browsere giver ingen problemer i nogle af tilfældene.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Jesper,

Firefox gør da som den skal, når du sender "Content-Type: application/octet-stream" ud til den.

Er der noget i HTTP-protokollen, der siger, at en klient skal prompte en bruger for "Gem", hvis der sendes en application/octet-stream?

Mig bekendt er det derimod

content-disposition=attachment; filename=Pletskud6.html

til netop dette?

Se evt http://www.ietf.org/rfc/rfc2183.txt afsnit 2.2, hvor der står:

2.2 The Attachment Disposition Type

Bodyparts can be designated `attachment' to indicate that they are separate from the main body of the mail message, and that their display should not be automatic, but contingent upon some further action of the user. The MUA might instead present the user of a bitmap terminal with an iconic representation of the attachments, or, on character terminals, with a list of attachments from which the user could select for viewing or storage.

  • 0
  • 0
Claus Stovgaard

Se http://tools.ietf.org/html/rfc2046#section-4.5.1

<snip>
The recommended action for an implementation that receives an "application/octet-stream" entity is to simply offer to put the data in a file, with any Content-Transfer-Encoding undone, or perhaps to use it as input to a user-specified process.

To reduce the danger of transmitting rogue programs, it is strongly recommended that implementations NOT implement a path-search mechanism whereby an arbitrary program named in the Content-Type parameter (e.g., an "interpreter=" parameter) is found and executed using the message body as input.
</snip>

Så når Chrome, Firefox og andre browser der følger anbefalingen modtager det du sender ud, så skal de spørge om man ønsker at gemme filen.

Hvis andet ønskes, så vil jeg i højste grad anbefale at fikse webserveren, så den følger RFC.

  • 0
  • 0
Benny Allan Andersen

Så når Chrome, Firefox og andre browser der følger anbefalingen modtager det du sender ud, så skal de spørge om man ønsker at gemme filen.

Hvis andet ønskes, så vil jeg i højste grad anbefale at fikse webserveren, så den følger RFC.

Men de 2 sider er ens. Det er kun måden, de er uploaded til mac.com, der er forskellig.

  • 0
  • 0
Benny Allan Andersen

En gang til. Jeg tror, jeg bliver misforstået.

http://homepage.mac.com/brumleby/Omegn6.html

http://homepage.mac.com/brumleby/Omegn6_2.html

De 2 html-sider er fuldstændig ens, sidder på den samme server - i den samme folder. Safari og Internet Explorer åbner begge sider helt korrekt, mens Firefox kun kan åbne den øverste. Altså må der være noget galt med Firefox.
Firefox er stadigt betydelig bedre til at afspille større .giffer og udmærker sig ved hurtighed under opstart og download; men altså........

  • 0
  • 0
Erik Jacobsen

De er jo ikke ens, som det er beskrevet ovenfor. HTTP-headeren er forskellig, og det er noget webserveren har gjort.

Hvordan det er sket, ved vi ikke. Men det er altså ikke FF, der gør noget forkert her. Det er den pågældende webserver.

  • 0
  • 0
Benny Allan Andersen

Hvordan det er sket, ved vi ikke. Men det er altså ikke FF, der gør noget forkert her. Det er den pågældende webserver.

Den viser da ikke siden Omegn6_2.html, og det gør de andre browsere. Så Firefox er dårligere end de andre browsere. Jeg er som bruger ligeglad med, hvad der teknisk set er rigtigt eller forkert. Jeg vil bare se html-siden, og kan den ikke vise den, så er der noget galt med den.

  • 0
  • 0
Erik Jacobsen

Nej og nej. Webserveren serverer siden med en HTTP-header, der siger at den skal downloades. Hvis en browser viser dig siden, er det den browser, der gør det forkert. Længere er den ikke.

Browsere skal ikke gætte på hvad de skal - de skal overholde standarderne.

Hvorfor den webserver du bruger, så ikke kan finde ud af det, det ved vi ikke. Men du kan jo spørge dem.

  • 0
  • 0
Claus Stovgaard

Hej Benny

Selvom jeg ikke kender systemet, vil jeg gerne komme med et bud på hvad problemet er. Hvis du benytter wget eller tilsvarende vil du se følgende omkring headeren:

Omegn6.html
<snip>
wget -S http://homepage.mac.com/brumleby/Omegn6.html

--2009-12-22 10:56:50-- http://homepage.mac.com/brumleby/Omegn6.html

Resolving homepage.mac.com... 17.250.248.34

Connecting to homepage.mac.com|17.250.248.34|:80... connected.

HTTP request sent, awaiting response...

HTTP/1.0 200 OK

Date: Tue, 22 Dec 2009 09:56:51 GMT

Content-Length: 15505

Content-Type: text/html

Cache-Control: max-age=60, must-revalidate

Connection: keep-alive

Proxy-Connection: keep-alive

Server: AppleIDiskServer-1F3014

x-responding-server: hpng003

Set-Cookie: mmr=nk11r10; Domain=homepage.mac.com; Path=/brumleby

Set-Cookie: mmr=nk11r10; Domain=homepage.mac.com; Path=/brumleby

X-dmUser: brumleby

ETag: "u-1g3s18hn-902p-ikpyjuo1a-25bs85ze5r0"

Last-Modified: Sun, 18 Oct 2009 03:27:18 GMT

Via: 1.1 hpcache006 (NetCache NetApp/6.0.5P2D2)

</snip>

Omegn6_2.html
<snip>
wget -S http://homepage.mac.com/brumleby/Omegn6_2.html

--2009-12-22 10:57:42-- http://homepage.mac.com/brumleby/Omegn6_2.html

Resolving homepage.mac.com... 17.250.248.34

Connecting to homepage.mac.com|17.250.248.34|:80... connected.

HTTP request sent, awaiting response...

HTTP/1.0 200 OK

Date: Tue, 22 Dec 2009 09:57:42 GMT

Content-Length: 15505

Content-Type: application/octet-stream

Cache-Control: max-age=60, must-revalidate

Connection: keep-alive

Proxy-Connection: keep-alive

Server: AppleIDiskServer-1F3014

x-responding-server: hpng014

Set-Cookie: mmr=nk11r10; Domain=homepage.mac.com; Path=/brumleby

Set-Cookie: mmr=nk11r10; Domain=homepage.mac.com; Path=/brumleby

X-dmUser: brumleby

ETag: "c-1g3s18hn-2clp-p8myk1jqd-1pt1ceze870"

Last-Modified: Tue, 22 Dec 2009 09:53:59 GMT

Via: 1.1 hpcache008 (NetCache NetApp/6.0.5P2D2)

</snip>

Hvis du ser på Content-Type, så sender din webserver 2 forskellige ting ud.

Forskellen kan skyldes at der gemmes noget metadata omkring filerne når du uploader dem til systemet. Den metadata vil fortælle hvordan webserveren skal servere filen til brugerne.

Hvordan du så ændre det, skal jeg ikke lige kunne sige, da jeg aldrig har rodet med MAC. Held og lykke med opgaven i hvert fald, da du nu har en ide om hvad årsagen er.

  • 0
  • 0
Mark Gjøl

Det er netop webservere som den der tvinger browsere til at ignorere standarderne og gætte sig frem. Som Benny siger, så anser han Firefox som noget skrald, fordi den gør hvad den skal, og skifter derfor til en browser der er ligeglad med hvad serveren fortæller den. Det er desværre ofte den laveste fællesnævner der vinder, da brugeren jo ikke anser problemet som værende hos serveren (Det virker på ie!) men hos klienten. Og selv når det så tydeligt som her kan påvises at det nødvendigvis er serveren der opfører sig sært - hvordan skulle browseren have nogen viden om hvordan filen er lagt på serveren?

Standarder kæmper en hård kamp mod firmaer der er ligeglade med dem, men jeg er imponeret over at vi er nået så langt som vi er!

  • 0
  • 0
Log ind eller Opret konto for at kommentere