IIS 7.5 -- Valami 48K

 ( NevemTeve | 2017. augusztus 23., szerda - 20:37 )

Ugyebár ez nem jó, ami valami, az harminc, nem pedig 48 KB.

Valahogy 'hozzápiszkálódott' az IIS konfigjához (csakis a marsklakók lehettek, mert mindenki más tagad (még a Windows Update-ot is gyanusítom)), és emiatt valamilyen 48 KB -s korlát lett a POST-méretére (kidebuggoltam 49152 még ok, 49153 már nem)

Valamilyen SOAP-os ASP.NET-es okosság is van a történetben, csak hogy érdekesebb legyen.

POST /Path/Product.svc HTTP/1.1
User-Agent: Wget/1.16 (aix5.3.0.0)
Accept: 
Host: 10.12.91.97
Connection: Keep-Alive
Content-Type: text/xml; charset=UTF-8
Content-Length: 49153
SOAPAction: "http://fiktivurl.org/Path/Action"

HTTP/1.1 413 Request Entity Too Large
Content-Type: text/html
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Wed, 23 Aug 2017 18:32:13 GMT
Connection: close
Content-Length: 67

Szerk: Random linkek, lehet, hogy releváns:
https://docs.microsoft.com/en-us/iis/configuration/system.webserver/asp/limits
https://forums.iis.net/p/1108662/1702390.aspx#1703071
https://stackoverflow.com/questions/22762311/the-page-was-not-displayed-because-the-request-entity-is-too-large-iis7
https://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/7e0d74d3-ca01-4d36-8ac7-6b2ca03fd383.mspx?mfr=true

Azt vélem érteni, hogy a wget meg az IIS kiépíti ugyan az SSL kapcsolatot, de a pluginként megvalósított program még maga is maszturbékolni akar a kliens certificate-jével. De a kliens épp a POST-BODY elküldésével van elfoglalva, nincs neki érkezese ilyen évődésre. Esetleg egy Expect: 100-Continue' segítene à la curl?

20170824.0719
Ja, 100-Continue segít. Aztán felébredtem, és kipróbáltam:

> Content-Length: 49153
> Expect: 100-continue
> 
< HTTP/1.1 100 Continue
* We are completely uploaded and fine
< HTTP/1.1 413 Request Entity Too Large

+1 link: http://blogs.catapultsystems.com/rhutton/archive/2012/07/22/request-entity-is-too-large-over-ssl-in-iis-7/

A teljesség kedvért: UploadReadAheadSize a gyanusított neve, default értéke 48 KB

20170825.2005 Na, megnövelték az UploadReadAheadSize-t, megjavult a működés. És kiderült, hogy nem nyúlt senki ehhez a beállításhoz (mivel a létezéséről sem tudott senki), hanem a 'mess around with client's certificate' nevű beállításhoz piszkáltak hozzá.
Állítólag egy másik partner ezt kérte. Valószínűleg olyan szép kliensoldali certificate-ja van, hogy szeretné, ha a szerver úja meg újra megcsodálná... vagy valami ilyesmi. Ebben az iparban sok furcsa ember van, csak én vagyok helikopter...

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

kedvencem az ilyen blogok (a catapultsystemes a legalján, ahol a megoldást írták a problémára):

"in this instance, we set it to 204000"

Oszt mondatvége, blogposztvége, pont b+ ! Indoklás? Lófasz. Pont mint vmi agyatlan indiai kókler blogján (de sajnos már techneten is egyre több ilyen "távolkeleti" hülye bloggolja a közveszélyes tanácsait): mi lesz a következménye ha átállitom? Mi mást fog eltörni ha észnélkül elkezdem növelgetni? Csak van oka h. a barom MSFT 48k-ra lőtte be a default-ot. Aáá, az nem érdekes, itt,van rakd be 204000-re oszt jó lesz.

Hasonló mint amikor vmi ssl-es szopás van: vmelyik hülye indiai/kínai megtalálja a csoda regkeyt amiről azt se tudja pontosan mire való de ami véletlenül pont "megoldja" az issue-t. Csak mellékesen még letiltja a TLS1.0-t is! Amiatt meg éppen eltörik vmelyik legacy MSFT szar, ami max TLS1.0-t tudott. De addigra már gugli bekesselte az indiai hülye megoldását, mindenki írja h. neki is ez segített (az adott legacy MSFT szart ő pont nem futtatja v. nem azonnal esik le neki a törés ténye) és terjed a kókler-megoldás mint a futótűz.

Megpróbálom érthetőbben leírni, hogy miben látom a problémát:

1. az IIS és a kliens kiépítik az SSL-kapcsolatot, kölcsönösen megcsodálják egymás certificate-jeit (ha akarják)
2. kliens küldi a HTTP-fejrészt meg a POST-datát
3. IIS a HTTP-fejrész alapján látja, hogy plugint kell hívni (nem ismerem a korrekt szakkifejezést, nevezzük 'asp.net program'-nak), és átadja a pluginnak a TCP/SSL kapcsolatat, meg a már beolvasott adatmennyiséget [szerk: ami nem a teljes POST-data, csak az első 48KB, a többi még a "csőben" van]
4. a plugin (avagy 'asp.net program') valamiért úgy érzi, hogy ő még mesterkedni akar a kliens certificate-jével, ezért pótlólagos opcióegyeztetést kér a klienstől
5. a kliens persze úgy vágyik az ilyen utólagos egyeztetésre, mint mókus az erdőtűzre, de ő történetesen a POST-data elküldése közben van, tehát az opcióegyeztetés nem lehetséges.
6. szerveroldal szomorog, küldi a HTTP-413-at, kliensoldal is szomorog
7. felhasználó is szomorog, elmegy az üzemeltetőhöz, aki mindenféle konfigban mindenféle hatalmas számot mutat neki, de pont ezt az UploadReadAheadSize-t nem, mert ez default-ból jön (vagy a registry egyik legeldugottabb zugából).

Szerk: Off: TLSv1.0-ról szólva: na azt én is szeretném tudni, hogy ugyanez az IIS 7.5 miért nem lát tovább az orránál a TLS1_0-nál:

IIS 7.5-höz kapcsolódva tesztprogrammal:
proto=TLSv1 enc=AES(128) mac=SHA1 kx=RSA au=RSA

Apache-2.4.27-hez kapcsolódva tesztprogrammal:
proto=TLSv1.2 enc=AESGCM(256) mac=AEAD kx=ECDH au=RSA