2009-05-07 12 views
25

Questa domanda è uno spin-off/evoluzione di this question. (Quella domanda è stata contrassegnata come risolta perché ho messo una bounty su di essa e si è risolta automaticamente, ma non ha mai avuto risposta.)IE 8 caduta di pagine di memoria?

Il riepilogo è questo: abbiamo un sito ASP.NET. A volte otteniamo errori quando il cliente chiede bizzarri URL. Dalle risorse che il cliente sta chiedendo, sembra che ci sia un blocco di testo di 4k mancante dal sorgente html.

Un semplice esempio ... se abbiamo una pagina che assomiglia a questo:

<a href="myValidLink.aspx">Here's some text</a> 
a bunch more stuff 
...(a large block of text)... 
AND NOW MORE STUFF LATER 

Il cliente può richiedere l'url: "myValidLiORE% 20STUFF% 20LATER".

Si comporta come se una sezione della sorgente HTML non fosse proprio lì ... e quella sezione che manca sembra essere esattamente 4KB (4096 byte) lungo (o secondo alcune persone, a volte 1KB?).

Purtroppo, non siamo in grado di replicare questo errore su richiesta, anche se lo vediamo arrivare dai client molte volte al giorno.

All'inizio abbiamo pensato che si trattasse di un problema con Webresource.axd, perché ci è capitato di vederlo molto ... ma ora penso che fosse principalmente perché stavamo raggruppando errori simili insieme e quegli errori tendevano a verificarsi quando si è verificata la corruzione in quella particolare area. Ora che sto esaminando una gamma più ampia di problemi, vedo luoghi in cui si verificano errori molto diversi che sembrano causati dallo stesso problema di eliminazione di un blocco.

Abbiamo visto molto con IE 8, ed è diventato più frequente in quanto IE 8 è diventato più diffuso. Lo vediamo occasionalmente con un browser che si segnala come IE 7 ... che IE 8 farà se viene messo in "modalità compatibilità".

La mia teoria, a questo punto (che sto cercando di trovare un modo per testare) è che il server web sta inviando correttamente tutti i dati nel flusso di byte ... e che il browser, IE 8 , ha un problema e rilascia una pagina di memoria (4k) in alcune condizioni.

Sono un po 'preoccupato per questa teoria, tuttavia, poiché apparentemente alcune persone hanno riferito di aver visto questo "occasionalmente" con IE 6 o FF 3 ... questi tendono ad essere valori anomali e potrebbero essere solo problemi diversi con simili i sintomi, ma se fosse davvero la stessa cosa su quei browser, ciò spazzerebbe via la mia teoria dall'acqua. Tuttavia, non ho un'idea migliore a questo punto.

Un'altra idea che ho avuto è forse un service pack relativamente recente sul server che sta causando problemi con i dati forniti ai client, lasciando cadere l'occasionale 4KB. Il problema con questa teoria è che non spiega la grande preponderanza degli errori su IE 8 e la loro mancanza su altri browser client.

Quindi le domande, che si spera alla fine avere risposte:

  1. Qualcun altro ha incontrato questo? (forse ora che è sul tuo radar?)
  2. Qualcuno può replicare questo problema in modo coerente?
  3. Qualche idea di cosa sia? Puoi verificare o confutare la mia teoria?
  4. Esistono correzioni o soluzioni?
+1

Aggiornamento: l'errore 4k è stato corretto dall'aggiornamento cumulativo IE8 del 30/03/2010. http://blogs.msdn.com/ieinternals/archive/2010/04/01/IE8-Lookahead-Downloader-Fixed.aspx – EricLaw

risposta

12

** Modifica 4/1/10: ** Aggiornamento: Il bug di 4k è stato corretto dall'aggiornamento cumulativo IE8 del 30/03/2010. blogs.msdn.com/ieinternals/archive/2010/04/01/

Il team di Internet Explorer ha esaminato questo problema.

- = = Impact -

Finora, riteniamo che il problema non ha alcun impatto sull'esperienza dell'utente finale con l'applicazione web; l'unico effetto negativo sono le richieste spurie/malformate inviate dal motore di download speculativo di JavaScript. Quando lo script è effettivamente necessario al parser, verrà scaricato e utilizzato correttamente in quel momento.

- = circostanze = -

Il spurie richiesta sembra verificarsi solo in determinate situazioni di temporizzazione, solo quando il pre-parser è costretto a riavviare (come quando un tag META http-equiv contenente un Content-Type con una direttiva CHARSET appare nel documento) e solo quando un URL SRC JavaScript si estende sul 4096 ° byte del corpo della risposta HTTP.

- = Soluzione = -

Al momento che questo problema può essere generalmente mitigata dichiarando il set di caratteri della pagina utilizzando l'intestazione HTTP Content-Type piuttosto che specificare che all'interno della pagina.

Quindi, piuttosto che mettere

[META http-equiv = "Content-Type" content = "text/html; charset = utf-8"]

nel tag testa, invece, inviare la seguente intestazione di risposta HTTP:

Content-Type: text/html; charset = utf-8

Si noti che la specifica del set di caratteri nell'intestazione HTTP comporta un miglioramento delle prestazioni in tutti i browser, poiché i parser del browser non devono riavviare l'analisi dall'inizio incontrando la dichiarazione del set di caratteri. Inoltre, l'utilizzo dell'intestazione HTTP aiuta a mitigare alcuni vettori di attacco XSS.

+1

http://blogs.msdn.com/ieinternals/archive/2009/07/27/ Bugs-in-the-IE8-Lookahead-Downloader.aspx – EricLaw

+0

L'impostazione di un'intestazione HTTP in IIS la utilizza per tutte le richieste, anche per fogli di stile e immagini. C'è un modo per farlo senza impostarlo in IIS? – goldenratio

+1

È possibile utilizzare un filtro ISAPI oppure il codice ASP/ASPX viene aggiunto manualmente. Tuttavia, come notato sopra sul blog di IEInternals, abbiamo determinato che esistono diversi modi per attivare il comportamento del buggy e sfortunatamente il riavvio del pre-parser a causa di charset è solo uno di questi. È necessaria una correzione nel browser per eliminare davvero questo problema. Aggiornamento – EricLaw

2

http://blogs.msdn.com/ieinternals/archive/2009/07/27/Bugs-in-the-IE8-Lookahead-Downloader.aspx è il post corrente su questo problema.

The Missing Bug 4k: L'articolo afferma: "Dichiarando il set di caratteri della pagina utilizzando l'intestazione HTTP Content-Type piuttosto che specificare che all'interno della pagina, è possibile rimuovere una delle cause di riavvio del parser" Eric Lawrence in un'email: "Sfortunatamente, un'altra causa nota di riavvio del parser è l'uso di spazi dei nomi XML, che il tuo sito sembra utilizzare." Quindi, se usi XHTML, il problema 4K può verificarsi!

0

Abbiamo lo stesso problema. Sto aggiungendo:

 Response.ContentType = "text/html" 
     Response.Charset = "utf-8" 

alla nostra classe di pagina di base. Riferirò brevemente ai risultati.

+0

Non c'è fortuna: il problema è ancora presente. – ChickenMilkBomb

0

FWIW Ecco le statistiche che ho ottenuto da 1 mese di log in LogParser.

12331 hits to ScriptResource & WebResource/183 errors

Ripartiti da info useragent.Sembra supportare la teoria di IE8 (oltre agli user agent della "modalità di compatibilità").

 
cs-uri-stem   MSIEVersion TridentVersion COUNT 
/WebResource.axd  MSIE+8.0 Trident/4.0  100 
/ScriptResource.axd MSIE+8.0 Trident/4.0  36 
/WebResource.axd  MSIE+7.0 Trident/4.0  44 
/ScriptResource.axd MSIE+7.0 Trident/4.0  2 
/ScriptResource.axd NOT IE  NOT Trident  1 

Il singolo errore non IE8 non ha querystring a tutti, proveniente da un Firefox/3.5.3 del browser (avuto modo di essere non correlato).

Non ho META HTTP-EQUIV = "Content-Type" nelle mie pagine. Anche se ho questo per rimbalzare gli utenti non Javascript.

<noscript> 
    <meta http-equiv=Refresh content="0; URL=/ErrorPage.aspx?Error=NoJavascript"> 
</noscript> 
Problemi correlati