Log IIS menunjukkan sc-win32-status = 64 tetapi hanya melalui beberapa jaringan

Saya memiliki aplikasi ASP.NET yang berjalan di server klien (W2k3, IIS6, .NET 2.0). FWIW, ini adalah contoh Uji , belum dipindahkan ke Produksi . Jadi itu tidak berjalan di bawah SSL, load balancing, dll.

Ketika saya mengakses salah satu halaman di server mereka dari kantor kami, halaman tersebut terkena sekali. Memeriksa log IIS (c: WINDOWS \ system32 \ LogFiles \ W3SVC1) menunjukkan GET untuk halaman itu, kemudian saya menekan tombol pada halaman dan file log menunjukkan POST. Sejauh ini tampaknya berfungsi dengan baik.

Sekarang ketika saya jauh ke jaringan klien dan mengakses halaman dari salah satu mesin lokal mereka, file log menunjukkan GET, kemudian saya menekan tombol pada halaman dan log menunjukkan dua POST pada detik yang sama. Yang pertama menunjukkan status (sc-status, sc-substatus, sc-win32-status) 200 0 64, yang kedua menunjukkan 200 0 0.

Dalam file log, kedua POST identik. Pada dasarnya log terlihat seperti ini (kecuali saya menyembunyikan beberapa data):

#Pasangan: waktu-tanggal s-ip cs-metode cs-uri-stem cs-uri-query s-port cs-nama pengguna c-ip cs (Pengguna-Agen) sc-status sc-substatus sc-win32-status 
2009-08-11 20:19:32 xxxx DAPAT /File.aspx - 80 - yyyy Mozilla / 4.0 + (kompatibel; + 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 + (kompatibel; + 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 + (kompatibel; + 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

Masalahnya adalah , halaman tersebut terkena dua kali. Database melakukan operasi untuk permintaan pertama, kemudian permintaan kedua mendeteksi bahwa operasi duplikat sedang dilakukan dan melempar pesan kesalahan. Para pengguna berpikir operasi mereka gagal, tetapi sebenarnya berhasil.

Deskripsi kesalahan sc-win32-status 64 adalah: "Nama jaringan yang ditentukan tidak lagi tersedia." Ini membuat saya percaya, mengingat bahwa kedua permintaan POST menunjukkan status HTTP 200, bahwa server berhasil dalam melayani permintaan, tetapi klien tidak pernah diberitahu dan mengirim kembali permintaan.

• Bagaimana saya bisa memecahkan masalah ini?

• Adakah ide yang dapat menyebabkan perilaku ini hanya di jaringan internal mereka?

• Saya harus menyebutkan, ini terjadi di dua situs klien yang terpisah, tetapi tidak terjadi di enam situs klien kami yang lain, atau di kantor kami, atau menghubungkan ke salah satu dari delapan klien kami melalui web.

• Apa yang membuat ini dapat direproduksi 100% dari waktu di jaringan lokal mereka tetapi 0% dari waktu di tempat lain?

Pembaruan: Saya menemukan sejumlah kecil permintaan POST duplikat memiliki sc-win32-status 995 bukannya 64 seperti yang dilaporkan semula. Deskripsi kesalahan sc-win32-status = 995 adalah: "Operasi I / O telah dibatalkan karena keluar dari utas atau permintaan aplikasi." Ini tidak masuk akal (mengingat saya memiliki akses penuh ke kode). Saya masih tidak mengerti bagaimana atau mengapa masalah ini terjadi, tetapi kode kesalahan yang baru membuat saya percaya bahwa ini mungkin bukan masalah jaringan dan saya sekarang sedang menyelidiki kemungkinan bug kode acak.

Ini adalah pemahaman saya tentang masalah sejauh ini:

• sc-win32-status 64 berarti "Nama jaringan yang ditentukan tidak lagi tersedia."
• Setelah IIS mengirim respons terakhir ke klien, biasanya menunggu pesan ACK dari klien.
• Terkadang klien akan mengatur ulang koneksi alih-alih mengirim ACK final kembali ke server. Ini bukan koneksi yang anggun, jadi IIS mencatat kode “64”.
• Banyak klien akan mengatur ulang koneksi setelah selesai, untuk membebaskan soket alih-alih meninggalkannya di TIME_WAIT / CLOSE_WAIT.
• Proxy cenderung melakukan ini lebih dari yang lain.

Pembaruan: Saya menemukan beberapa informasi menarik di sini dan di sini , jadi saya pada dasarnya menulis ulang halaman untuk memastikan tidak ada markup yang buruk, dll. Dan ... masalahnya sekarang hilang! Itu hanya tembakan dalam kegelapan, dan saya tidak bisa mengatakan dengan pasti apa yang memperbaiki masalah, karena itu hanya memengaruhi beberapa klien kami dalam beberapa keadaan yang sangat spesifik ...

Saya mengalami masalah yang sama ketika mencoba untuk melayani file biner gzip dari IIS6 melalui server proxy. Saya tidak mengalami masalah saat mengunjungi situs web secara langsung.

Saya menemukan ini adalah penyebab dalam kasus saya dengan menjalankan Fiddler pada mesin klien dan memeriksa responsnya. Fiddler memperingatkan bahwa responsnya dikodekan dan kemudian mengeluh bahwa angka ajaib pada file gzip tidak benar.

Saya mematikan kompresi gzip untuk file biner dalam kode saya dan masalah ini berhenti terjadi.

Saya bukan ahli dalam hal ini tetapi saya menemukan masalah serupa yang hanya terjadi ketika menggunakan alamat IP daripada nama host.

Mungkin itu sedikit membantu ...

Tikar.