Firefox 3.5 er verdens største browser

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

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?

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.

Det er Firefox (og i øvrigt også Chrome) som opfører sig korrekt. At andre browsere ignorerer Content-Type er ikke så smart, og gør fx at man ikke kan lave et download link til en filtype som browseren selv kan vise.

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.

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.

Hej Claus,

<snip> (...) </snip>

I stand corrected :o)

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.

"Det er kun måden, de er uploaded til mac.com, der er forskellig." - derfor er det jo stadig webserveren, der gør det forkert.

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å........

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.

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.

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.

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.

Tak.
Nu har jeg noget, jeg kan fodre Apple med og måske få en forklaring - og måske en update. :-)

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!

Det absurde er så, at når man surfer ind på http://homepage.mac.com, så får man at vide, at Safari og Firefox (!) er supporterede browsere.

Jeg får naturligvis advarslen, da jeg bruger Iceweasel. Gode gamle.