Askeskyen væk: Flyene er oppe - hjemmesiden er nede

OPDATERET: Københavns Lufthavnes hjemmeside cph.dk er på grund af vulkanasken gået fra 20.000 daglige besøg til 4,5 millioner. Derfor har virksomheden i stedet for det normale site valgt at lægge et såkaldt dark site på.

Flyene letter igen fra Københavns Lufthavn, efter den meget omtalte askesky er på vej væk fra dansk luftrum.

Det har medført et så massivt pres på lufthavnens hjemmeside, at cph.dk i øjeblikket består af et såkaldt dark site med kun de allermest nødvendige informationer.

Således bliver man i skrivende stund mødt af denne besked, når man går ind på www.cph.dk:

»Københavns Lufthavn er åben. Flyvesikringstjenesten Naviair har åbnet luftrummet over hele Danmark foreløbig indtil kl. 02:00 (22. april) Næste opdatering fra Naviair ventes ca. kl. 15:00.

Passagererne skal kontakte deres flyselskab eller rejsebureau for mere information.«

Herefter følger fire links til afgange og ankomster for henholdsvis udenrigs- og indenrigstrafikken, og det hele gentages så på engelsk.

»Det, der er sket i denne 'askekrise', er, at vi er gået fra cirka 20.000 daglige besøg til lige under 4,5 millioner,« fortæller it-direktør Christian Poulsen fra Københavns Lufthavne til Version2.

Den normale udgave af hjemmesiden indeholder en række forskellige informationer om både flyafgange og forskellige kommercielle tilbud. Det er information, der trækkes fra mange databaser.

»I denne situation har vi erkendt, at det havde folk ikke behov for, og vi havde ikke maskinkraft nok. Hvis lufthavnen er lukket, så er der ingen grund til at fortælle, at hvert fly er aflyst, så vi sparer nogle databaseopslag på den konto,« siger Christian Poulsen.

Den seneste melding lyder på, at luftrummet fortsat er åbent, men trafikken er stadig høj på cph.dk. Ifølge Christian Poulsen er hjemmesiden nu flyttet over på en kraftigere webserver, men indtil videre kører lufthavnene videre med det begrænsede site, fordi trafikken stadig er høj.

Han forventer at skifte tilbage fra det begrænsede dark site til det normale site, når trafiksituationen både i luften og på webserveren igen begynder at nærme sig det normale niveau.

Et 'dark site' er i kommunikationsbranchen defineret som en simpel webside på få kilobyte, der i krisesituationer kan lægges på forsiden af virksomhedens website. Fidusen er, at serveren kan klare langt flere hits uden at bukke under, samtidig med, at virksomheden får lagt fokus på netop de budskaber, der er vigtige i forbindelse med den aktuelle krise.

Opdateret onsdag den 21. april klokken 16:55

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jan Christensen

Det ser dog ud til at hele hjemmesiden stadigvæk fungerer, og at det kun er forsiden der er ændret.

Klikker man på en af linksne på forsiden, kommer man videre og får derefter den normale menu i toppen hvor efter man kan navigere videre.

  • 0
  • 0
Jørn Schou-Rode

Hos mig (Firefox 3.6, Arch Linux) ser CPH.dk bestemt ikke "mørk" ud, men snarere lys gul/orange. Indhold er der til gengæld ikke meget af:

[code=text]XML Parsing Error: not well-formed
Location: ht tp://ww w.cph.dk/CPH/Darksite/Darksite.htm
Line Number 5, Column 85:[/code]
Er det nogen herinde der ved om man kan tvinge Firefox til at fortolke siden som text/html når serveren påstår application/xhtml+xml? Det er ikke første gang jeg oplever dette problem, og det jo ikke altid man har Internet Explorer i baghånden :(

  • 0
  • 0
Lars Tørnes Hansen

@Jørn Schou-Rode, 21. april 2010 16:14

"application/xhtml+xml" og "XML Parsing Error: not well-formed" har ikke noget Internet Explorer at gøre.

"application/xhtml+xml" betyder at du har fået et XHTML dokument (http://en.wikipedia.org/wiki/XHTML), og fejlmeddelelsen siger at dokumentet ikke er "well-formet", som betyder at tags/slut-tags ikke er placeret rigtigt i dokumentet:

well-formet XHTML sekvens: <i><b>noget tekst her</b></i>
ikke well-formet XHTML sekvens: <i><b>noget tekst her</i></b>

  • 0
  • 0
Jørn Schou-Rode

@Lars Tørnes Hansen, 21. april 2010 17:29

Beklager at jeg ikke var specifik nok i mit spørgsmål. Jeg er helt med på årsagen til problemet (defekt/forkert markup ift. valg af content-type).

Min erfaring siger mig dog at Internet Explorer er temmelig tilgivende på denne front - måske fordi den parser som HTML uanset content-type, eller fordi serveren vælger at servere text/html til denne i stedet. Firefox afviser derimod blank at rendere defekte dokumenter med application/xhtml+xml.

Mit spørgsmål går således på, om der findes en indstilling i Firefox der siger "hvis du ikke kan parse det her som XML, så prøv som HTML tag soup i stedet for brok". Jeg er klar over at dette nok ikke er det mest oplagte forum til Firefox support, men nu kom spørgsmålet naturligt i forlængelse af et "dark site" som viste sig at være gult :)

  • 0
  • 0
Michael Eriksen

cph.dk kan heller ikke læses med Firefox 3.0.6, der er default i Debian Stable. Dillo kan heller ikke læse siden.

Når man laver en nødside, der endda ikke indeholder noget vildere end fed skrift og mailto-links, er det simpelthen dybt ukvalificeret at fucke det op.

Ikke overraskende kører de MS IIS, så det hele er nok outsourceset til Indien. Jubiii!

  • 0
  • 0
Jens Gyldenkærne Clausen

Allerførst - det ser ud til at cph.dk er blevet fikset nu - siden virker fint i Firefox, og der sendes helt standard text/html som content-type.

Min erfaring siger mig dog at Internet Explorer er temmelig tilgivende på denne front - måske fordi den parser som HTML uanset content-type, eller fordi serveren vælger at servere text/html til denne i stedet.

IE understøtter slet ikke application/xhtml+xml - den vil blot tilbyde dig at downloade indholdet hvis du forsøger at tilgå indhold med application/xhtml+xml.

Firefox afviser derimod blank at rendere defekte dokumenter med application/xhtml+xml.

Det skal den gøre - med application/xhtml+xml som contenttype behandles indholdet som et xml-dokument - og hvis der er fejl i xml-strukturen, skal xml-parseren stoppe og brokke sig.

Formentlig har siden brugt http-accept-headeren til at afgøre om browseren forstår application/xhtml+xml. Den header kan man redigere via about:config i firefox (network.http.accept.default) - hvis man fjerner application/xhtml+xml vil man formentlig modtage siden som text/html.

Som nævnt øverst ser det dog ud til at de har fjernet accept-header-snifferen igen - og der er da heller ingen grund til at benytte den slags på et helt almindeligt website.

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