Aracılığıyla paylaş

IIS'de HTTP 400 hatalarını giderme

Şunlar için geçerlidir: Internet Information Services

Bu makalede, IIS kullanırken çeşitli HTTP 400 hatalarının nedenini belirlemeye yönelik sorun giderme adımları açıklanmaktadır.

Genel Bakış

Bir HTTP istemcisi (Microsoft Edge gibi) BIR IIS sunucusuna HTTP isteği gönderdikten sonra aşağıdaki hata iletisi türünü görüntüleyebilir:

HTTP 400 - Hatalı İstek

Bu senaryoda, istek sunucunun HTTP ayrıştırma kurallarını karşılamadığından, zaman sınırlarını aştığından veya IIS veya HTTP.sys gelen isteklerin uymasını gerektirdiği diğer bazı kuralları başarısız olduğundan IIS istemcinin HTTP isteğini reddeder. IIS, durumu istemciye geri gönderir HTTP 400 - Bad Request ve ardından TCP bağlantısını sonlandırır.

Araçlar

Metotlarda sorun giderme

HTTP 400 koşuluyla ilgili sorunları giderirken, temel alınan sorunun istemcinin IIS'ye HTTP.sys zorunlu HTTP.sys bir veya daha fazla kuralı bozan bir istek gönderdiğini unutmayın. Bunu göz önünde bulundurarak istemcinin IIS'ye tam olarak ne gönderdiğini görmek istersiniz. Bunu yapmak için, hatalı isteği gönderen istemcinin ağ izlemesini yakalayın. İstemcinin IIS'ye gönderdiği ham verileri görmek ve IIS'nin istemciye geri gönderdiği ham yanıt verilerini görmek için izlemeyi analiz edebilirsiniz. İstemci ve sunucu SSL üzerinden iletişim kuruyor olsa bile HTTP üst bilgilerini görmenize olanak sağladığından, harika bir araç olan Fiddler adlı bir HTTP algılayıcı aracı da kullanabilirsiniz.

Kullanacağınız sonraki veri öğesi C:\Windows\System32\LogFiles\HTTPERR\httperr.log dosyasıdır. IIS'de, HTTP.sys bileşeni gelen HTTP isteklerini IIS'ye geçirilmeden önce işler ve IIS gereksinimlerini karşılamayan istekleri engellemekten sorumludur. HTTP.sys isteği engellediğinde, hatalı istek ve neden engellendiğiyle ilgili bilgileri httperr.log dosyasına kaydeder.

Not

HTTP.sys tarafından sunulan HTTP API hata günlüğü hakkında daha fazla bilgi için bkz . HTTP API'de hata günlüğü.

Teknik olarak mümkündür, ancak büyük olasılıkla olmasa da, istemcinin httperr.log dosyasında ilişkili bir günlük girişi olmayan bir HTTP 400 yanıtı alması mümkündür. ISAPI filtresi veya uzantısı ya da IIS'deki bir HTTP modülü 400 durumunu ayarlarsa bu durum oluşabilir. Bu durumda daha fazla bilgi için IIS günlüğüne bakabilirsiniz. Ayrıca, istemci ile sunucu arasındaki bir varlık (ara sunucu veya başka bir ağ cihazı gibi) IIS'den gelen bir yanıtı durdurur ve bunu kendi 400 durumu ve/veya "Hatalı İstek" hatasıyla geçersiz kılarsa da oluşabilir.

Not

Bu makalede, web sitenize ulaşmadan önce sık karşılaşılan HTTP 400 hataları ele alınmaktadır. Bazı senaryolarda, web siteniz özel kod mantığı veya çalışma zamanı (ASP.NET gibi) yapılandırması nedeniyle istemcilere HTTP 400 hataları da döndürebilir. Aşağıdaki bölümlerdeki adımları gerçekleştirdikten sonra HTTP 400 hatalarını yine de çözemiyorsanız, IIS'deki Başarısız İstek İzleme özelliğini kullanarak sorun gidermeyi deneyin. HTTP 400 hatalarının web sitenizin ASP.NET gibi ilgili çalışma zamanı işleyicisi tarafından ayarlandığını fark ederseniz, HTTP 400 hatalarının nedenini anlamak için web sitenizin ilgili kod mantığı ve çalışma zamanı yapılandırmasıyla birlikte isteklerin ve yanıtların ayrıntılarını incelemeniz gerekebilir.

Örnek senaryo

Aşağıda, istemcinin IIS'ye hatalı bir istek gönderdiği ve sunucunun "HTTP 400 - Hatalı İstek" iletisini geri gönderdiği BIR HTTP 400 senaryosu örneği verilmiştir.

İstemci isteğini gönderdiğinde, geri aldığı tarayıcı hatası şöyle görünür:

Hatalı İstek (Üst Bilgi Alanı Çok Uzun)

İstek ve yanıtın ağ izlemesini yakalayarak aşağıdaki çıkışları görürsünüz:

İSTEK:

HTTP: GET Request from Client
HTTP: Request Method =GET
HTTP: Uniform Resource Identifier =/1234567890123456789012345678901234567890/time.asp
HTTP: Protocol Version =HTTP/1.1
HTTP: Accept-Language =en-us
HTTP: UA-cpu =x86
HTTP: Accept-Encoding =gzip, deflate
HTTP: Host =iisserver
HTTP: Connection =Keep-Alive
HTTP: Data: Number of data bytes remaining = 14 (0x000E)

YANIT:

HTTP: Response to Client; HTTP/1.1; Status Code = 400 - Bad Request
HTTP: Protocol Version =HTTP/1.1
HTTP: Status Code = Bad Request
HTTP: Reason =Bad Request
HTTP: Content-Type =text/html
HTTP: Date =Wed, 14 Nov 2012 20:36:36 GMT
HTTP: Connection =close
HTTP: Content-Length =44
HTTP: Data: Number of data bytes remaining = 63 (0x003F)

Yanıt üst bilgilerinin tarayıcıdaki hata iletisi kadar fazla bilgi vermediğini fark edeceksiniz. Ancak yanıt gövdesindeki ham verilere bakarsanız daha fazlasını görürsünüz:

00000030                                           48 54               HT
00000040 54 50 2F 31 2E 31 20 34 30 30 20 42 61 64 20 52 TP/1.1.400.Bad.R
00000050 65 71 75 65 73 74 0D 0A 43 6F 6E 74 65 6E 74 2D equest..Content-
00000060 54 79 70 65 3A 20 74 65 78 74 2F 68 74 6D 6C 0D Type:.text/html.
00000070 0A 44 61 74 65 3A 20 57 65 64 2C 20 32 38 20 4A .Date:.Wed,.28.J
00000080 61 6E 20 32 30 30 39 20 32 30 3A 33 36 3A 33 36 an.2009.20:36:36
00000090 20 47 4D 54 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E .GMT..Connection
000000A0 3A 20 63 6C 6F 73 65 0D 0A 43 6F 6E 74 65 6E 74 :.close..Content
000000B0 2D 4C 65 6E 67 74 68 3A 20 34 34 0D 0A 0D 0A 3C -Length:.44....<
000000C0 68 31 3E 42 61 64 20 52 65 71 75 65 73 74 20 28 h1>Bad.Request.(
000000D0 48 65 61 64 65 72 20 46 69 65 6C 64 20 54 6F 6F Header.Field.Too
000000E0 20 4C 6F 6E 67 29 3C 2F 68 31 3E 01 02 03 04 05 .Long).....
000000F0 05 06 0E 94 63 D6 68 37 1B 8C 16 FE 3F D5       ....c.h7....?.

Tarayıcıda görüntülenen hata iletisi metninin ağ izlemesindeki ham yanıt verilerinde de görüntülendiğini görebilirsiniz.

Sonraki adım, hatalı isteğe karşılık gelen girişin C:\Windows\System32\LogFiles\HTTPERR dizinindeki httperr.log dosyasına bakmaktır:

#Software: Microsoft HTTP API 1.0
#Version: 1.0
#Date: 2012-11-14 20:35:02
#Fields: date time cs-version cs-method cs-uri sc-status s-reason 
2012-11-14 20:36:36 HTTP/1.1 GET /1234567890/time.asp 400 FieldLength

Bu senaryoda, Reason httperr.log dosyasındaki alan, sorunu tanılamak için ihtiyacınız olan tam bilgileri sağlar. HTTP.sys bu isteğin başarısız olmasının neden tümceciği olarak günlüğe kaydedildiğini FieldLength görürsünüz. Neden tümceciği hakkında bilgi edindikten sonra, AÇıKLAMASıNı almak için HTTP API'sinin günlüğe kaydedecekleri hata türleri bölümündeki tabloyu denetleyin:

FieldLength: Alan uzunluğu sınırı aşıldı.

Dolayısıyla bu noktada tarayıcı hata iletisinden ve HTTP API hata günlüğünden isteğin izin verilebilen uzunluk sınırlarını aşan HTTP üst bilgilerinden birinde veri içerdiğini biliyorsunuz. Bu örnekte, HTTP: Uniform Resource Identifier header amaçsal olarak uzun: /1234567890123456789012345678901234567890/time.asp.

Bu örnekte sorun giderme işleminin son aşaması, HTTP.SYS kayıt defteri anahtarlarını ve IIS için varsayılan ayarları denetlemektir

Neden tümceciği ve hatanın üst bilgi alanı uzunluğunun sınırları aştığını önerdiğini bildiğiniz için Kayıt Defteri Anahtarları tablosundaki aramamızı bu şekilde daraltabilirsiniz. Burada en önemli aday:

Kayıt defteri anahtarı Default value Geçerli değer aralığı Kayıt defteri anahtarı işlevi UYARI kodu
MaxFieldLength 16384 64 - 65534 (64k - 2) bayt Her üst bilgi için bir üst sınır ayarlar. Bkz. MaxRequestBytes. Bu sınır, URL için yaklaşık 32k karaktere çevrilir. 1

Bu örnekte bu hatayı yeniden oluşturmak için kayıt MaxFieldLength defteri anahtarı 2 değeriyle ayarlanmıştır. İstenen URL'nin ikiden fazla karakter içeren bir HTTP: Uniform Resource Identifier header alanı olduğundan, istek neden tümceciğiyle FieldLength engellendi.

Bir diğer yaygın HTTP 400 senaryosu, HTTP isteğinde bulunan kullanıcının çok sayıda Active Directory grubunun üyesi olduğu ve web sitesinin Kerberos kimlik doğrulaması kullanıcısı olarak yapılandırıldığı senaryodur. Bu senaryo oluştuğunda, kullanıcıya aşağıdakine benzer bir hata iletisi görüntülenir:

Hatalı İstek (İstek Üst Bilgisi Çok Uzun)

Bu senaryoda, istemcinin HTTP isteğinin bir parçası olarak eklenen kimlik doğrulama belirteci çok büyük ve http.sys zorlayan boyut sınırlarını aşıyor. Bu sorun, HTTP isteklerine yönelik HTTP 400 - Hatalı İstek (İstek Üst Bilgisi çok uzun) yanıtlarında çözümle birlikte ayrıntılı olarak ele alınmalıdır.

Başvurular

  • Last updated on