Dostaję dziwną odpowiedź ze strony, którą zamierzałem przeanalizować za pomocą FiddlerCore. W narzędziach deweloperskich w chrome, jeśli sprawdzę odpowiedź, wygląda to zupełnie normalnie, w skrzypku nie. Fragment kodu następująco (który pracował w porządku)FiddlerCore dekodowanie odpowiedzi sdch
String html = oSession.GetResponseBodyAsString();
Zwraca następujące dane, które nie jest HTML, trzeba pamiętać, że jest to próbka zamiast pełnej ogromny łańcuch.
JRHwJNeR\0���\0\0\u0001��D\0�2�\b\0�\u0016�7]<!DOCTYPE html>\n win\">
Jest również zaśmiecona "\ n" i HTML takie jak ta
\n\n\n\n\n \n <meta name=\"treeID\" content=\"dwedxE+pgRQAWIHiFSsAAA==\">\n
nagłówki odpowiedzi są następujące:
Cache-Control:no-cache, no-store
Connection:keep-alive
Content-Encoding:sdch, gzip
Content-Language:en-US
Content-Type:text/html;charset=UTF-8
Date:Fri, 28 Oct 2016 10:17:02 GMT
Expires:Thu, 01 Jan 1970 00:00:00 GMT
Pragma:no-cache
Server:Apache-Coyote/1.1
Set-Cookie:lidc="b=VB87:g=518:u=60:i=1477649823:t=1477731496:s=AQG-LTdly5mcIjAtiRHIOrKE1TiRWW-l"; Expires=Sat, 29 Oct 2016 08:58:16 GMT; domain=.thedomain.com; Path=/
Set-Cookie:_lipt=deleteMe; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/
Strict-Transport-Security:max-age=0
Transfer-Encoding:chunked
Vary:Accept-Encoding, Avail-Dictionary
X-Content-Type-Options:nosniff
X-Frame-Options:sameorigin
X-FS-UUID:882b3366afaa811400a04937a92b0000
X-Li-Fabric:prod-lva1
X-Li-Pop:prod-tln1-scalable
X-LI-UUID:iCszZq+qgRQAoEk3qSsAAA==
X-XSS-Protection:1; mode=block
Skrzypek kod startowy:
Fiddler.FiddlerApplication.AfterSessionComplete += FiddlerApplication_OnAfterSessionComplete;
Fiddler.FiddlerApplication.BeforeResponse += delegate(Fiddler.Session oS) {
oS.utilDecodeResponse();
};
Fiddler.FiddlerApplication.Startup(0, FiddlerCoreStartupFlags.Default);
}
Początkowo zakładałem, że to kawał ed/gzipped, więc dodałem utilDecodeResponse(); na onBeforeResponse, która nie przyniosła efektu!
Po to, by objąć wszystkie bazy, próbowałem również ręcznie odszyfrować responseBodyBytes w UTF-8, Unicode, Bigendian itp. Tylko przy okazji okazało się, że typ zawartości jest niepoprawny AND disabled javascript i załadowałem stronę, aby udowodnić, że to nie jest " t jakiś fajny szablon, co też nie miało znaczenia.
Wszelkie pomysły?
UPDATE:
Zgodnie z informacjami dostarczonymi przez autorów & NineBerry poniżej rozwiązania jest następująca:
W celu uniknięcia odpowiedzi będący SDCH kodowane można dodać moduł obsługi tak:
Fiddler.FiddlerApplication.BeforeRequest += delegate (Fiddler.Session oS)
{
oS.oRequest["Accept-Encoding"] = "gzip, deflate, br";
};
Należy zauważyć, że nie nadaje się do wszystkiego, ponieważ ręcznie ustawiasz nagłówki zamiast sprawdzać, czy SDCH jest obecny, a następnie go usunąć, dla moich celów to działa poprawnie, ale w przypadku korzystania z ogólnych funkcji proxy skrzypka, chciałbyś mieć tutaj więcej logiki.
Kodowanie treści jest wyświetlane jako 'sdch'. Czy ta pomoc? http://blog.endpoint.com/2009/07/sdch-shared-dictionary-compression-over.html – Developer
Oooo, to interesujący dokument, mógłbym skrzypka odrzucić/zmienić akceptowane nagłówki kodowania. –
Pozwól mi to przetestować się i wracaj, to ma sens, że będzie to kwestia, post i odpowiedź, a ja wrócę trochę! –