I registri IIS mostrano sc-win32-status = 64 ma solo attraverso alcune reti

Ho un'applicazione ASP.NET in esecuzione su un server client (W2k3, IIS6, .NET 2.0). FWIW, questa è un'istanza di test , non è stata ancora spostata in produzione . Quindi non funziona con SSL, bilanciamento del carico, ecc.

Quando accedo a una delle pagine sul loro server dal nostro ufficio, la pagina viene colpita una volta. L'ispezione dei registri IIS (c: WINDOWS \ system32 \ LogFiles \ W3SVC1) mostra un GET per quella pagina, quindi premo un pulsante sulla pagina e il file di registro mostra un POST. Questo sembra funzionare bene finora.

Ora, quando mi collego alla rete del client e accedo alla pagina da una delle loro macchine locali, il file di registro mostra un GET, quindi premo il pulsante sulla pagina e il registro mostra due POST allo stesso secondo. Il primo mostra lo stato (sc-status, sc-substatus, sc-win32-status) 200 0 64, il secondo mostra 200 0 0.

Nel file di registro, entrambi i POST sono identici. Fondamentalmente il registro si presenta così (tranne che ho mascherato alcuni dei dati):

#Campi: data ora s-ip metodo cs cs-uri-stem cs-uri-query s-port cs-username c-ip cs (User-Agent) sc-status sc-substatus sc-win32-status 
2009-08-11 20:19:32 xxxx GET /File.aspx - 80 - yyyy Mozilla / 4.0 + (compatibile; + MSIE + 8.0; + Windows + NT + 6.0; + WOW64; + Trident / 4.0; + SLCC1; + + .NET CLR + 2.0.50727;. + NET + CLR + 3.5.21022;. + NET + CLR + 3.5.30729;. + NET + CLR + 3.0.30618; + MDDR; + OfficeLiveConnector.1.4; + OfficeLivePatch .0,0) 200 0 0
2009-08-11 20:19:45 xxxx POST /File.aspx - 80 - yyyy Mozilla / 4.0 + (compatibile; + MSIE + 8.0; + Windows + NT + 6.0; + WOW64; + Trident / 4.0; + SLCC1; + + .NET CLR + 2.0.50727;. + NET + CLR + 3.5.21022;. + NET + CLR + 3.5.30729;. + NET + CLR + 3.0.30618; + MDDR; + OfficeLiveConnector.1.4; + OfficeLivePatch .0,0) 200 0 64
2009-08-11 20:19:45 xxxx POST /File.aspx - 80 - yyyy Mozilla / 4.0 + (compatibile; + MSIE + 8.0; + Windows + NT + 6.0; + WOW64; + Trident / 4.0; + SLCC1; + + .NET CLR + 2.0.50727;. + NET + CLR + 3.5.21022;. + NET + CLR + 3.5.30729;. + NET + CLR + 3.0.30618; + MDDR; + OfficeLiveConnector.1.4; + OfficeLivePatch .0,0) 200 0 0

Il problema è che la pagina viene colpita due volte. Il database esegue un'operazione per la prima richiesta, quindi la seconda richiesta rileva che è stata eseguita un'operazione duplicata e genera un messaggio di errore. Gli utenti pensano che la loro operazione sia fallita, ma in realtà è riuscita.

La descrizione dell'errore di sc-win32-status 64 è: "Il nome di rete specificato non è più disponibile." Questo mi porta a credere, dato che entrambe le richieste POST mostrano uno stato HTTP di 200, che il server riesce a soddisfare la richiesta, ma il client non viene mai avvisato e invia nuovamente la richiesta.

• Come posso risolvere questo?

• Qualche idea su cosa potrebbe causare questo comportamento solo sulla loro rete interna?

• Dovrei menzionare che ciò sta accadendo in due siti client separati, ma non accade in sei dei nostri altri siti client, o nel nostro ufficio, o che si connettono a nessuno dei nostri otto client sul Web.

• Cosa potrebbe rendere questo riproducibile il 100% delle volte sulla loro rete locale ma lo 0% delle volte in qualsiasi altro luogo?

Aggiornamento: ho scoperto che un numero molto limitato di richieste POST duplicate aveva lo stato sc-win32 di 995 anziché 64 come riportato in origine. La descrizione dell'errore di sc-win32-status = 995 è: "L'operazione di I / O è stata interrotta a causa dell'uscita di un thread o di una richiesta dell'applicazione." Questo non ha alcun senso (considerando che ho pieno accesso al codice). Continuo a non capire come o perché si stia verificando questo problema, ma il nuovo codice di errore mi fa pensare che potrebbe non essere un problema di rete dopo tutto e ora sto studiando la possibilità di un bug di codice casuale.

Questa è la mia comprensione del problema finora:

• sc-win32-status 64 significa "Il nome di rete specificato non è più disponibile."
• Dopo che IIS ha inviato la risposta finale al client, in genere attende un messaggio ACK dal client.
• A volte i client reimpostano la connessione invece di inviare l'ACK finale al server. Questa non è una chiusura aggraziata, quindi IIS registra il codice "64".
• Molti client reimposteranno la connessione al termine, per liberare il socket invece di lasciarlo in TIME_WAIT / CLOSE_WAIT.
• I proxy tendono a fare questo più di altri.

Aggiornamento: ho trovato alcune informazioni interessanti qui e qui , quindi ho praticamente riscritto la pagina per assicurarmi che non ci fosse alcun markup negativo ecc. E ... il problema ora è scomparso! Era solo uno scatto al buio e non potevo assolutamente dire quale fosse il problema risolto, dal momento che stava interessando solo alcuni dei nostri clienti in circostanze molto specifiche ...

Ho riscontrato questo stesso problema durante il tentativo di pubblicare file binari gzippati da IIS6 attraverso un server proxy. Non ho riscontrato alcun problema quando si accede direttamente al sito Web.

Ho scoperto che questa era la causa nel mio caso eseguendo Fiddler su un computer client e controllando la risposta. Fiddler avverte che la risposta è codificata e quindi si lamenta che il numero magico nel file gzip non era corretto.

Ho disattivato la compressione gzip per i file binari nel mio codice e il problema ha smesso di verificarsi.

Non sono un esperto di questo, ma ho riscontrato un problema simile che si è verificato solo quando si utilizza un indirizzo IP anziché un nome host.

Forse questo aiuta un po '...

Stuoia.