Thread View: pl.comp.www.server-side
16 messages
16 total messages
Started by marek.horodyski@
Fri, 02 Aug 2013 17:50
Dziwne requesty
Author: marek.horodyski@
Date: Fri, 02 Aug 2013 17:50
Date: Fri, 02 Aug 2013 17:50
125 lines
5252 bytes
5252 bytes
Dobry wieczór :) Startujê z serwowaniem www. Na razie nie mam czasu co¶ wiêcej stworzyæ, ale serwer stoi i takie puste strony mo¿e wystawiæ. Stoi se i "s³ucha", a tu takie niespodziewane wo³ania siê pojawiaj±, co do obs³ugi których mam szereg w±tpliwo¶ci i w zwi±zku z tym pytañ : ------------------ 83.212.111.98: GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1 Potem "entery" i nic wiêcej. Odpowied¼ posz³a 404. Ale co to by³o ?! ------------------ 46.36.35.233: GET / HTTP/1.0 i po tym 2 entery, nic wiêcej. Wiêc odpowid¼ posz³a 400, ale mo¿e powinna 303, spróbuj - tylko co dalej ? Z jakiej domeny ? Podobny problem bêdzie opisany ni¿ej z googlem. ------------------ 183.60.48.25: CONNECT tcpconn2.tencent.com:443 HTTP/1.1 Host: tcpconn2.tencent.com:443 Accept: */* Content-Type: text/html Proxy-Connection: Keep-Alive Content-length: 0 Oprogramowany jest tylko GET i POST, my¶lê o zaimplementowaniu te¿ PUT, ale to pó¼niej. Wiêc na razie serwer odpowiedzia³ 501 Not implemented. Ale co to wogóle za ¿±danie by³o ? Kto i co chcia³? Jaki connected? ------------------ 96.254.171.2: GET http://server5.cyberpods.net/azenv.php HTTP/1.1 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 (.NET CLR 3.5.30729) Host: server5.cyberpods.net Accept-Encoding: deflate, gzip Proxy-Connection: Keep-Alive Accept-Language: en-gb,en;q=0.5 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Pragma: no-cache Cache-Control: no-cache W ogóle nie kumam co on chcia³ - daje GET i jaki¶ adres, zamiast tam (bezpo¶rednio na ten adres) siê dobijaæ. Dosta³ w odpowiedzi 404 not found. Ju¿ po HTTP/1.1, du¿o zeznaje, ale czgo chce? Dobrze odpowiedzia³em ? ------------------ 62.236.108.240: 80.82.64.227: GET http://gameframe.net/headers HTTP/1.1 User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686 on x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 Host: gameframe.net Accept-Encoding: deflate, gzip Proxy-Connection: Keep-Alive Accept-Language: en-gb,en;q=0.5 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Pragma: no-cache Cache-Control: no-cache Z tego drugiego adresu ró¿nice w nag³ówku : User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0 Te¿ po GET dali link, a wiêc te¿ dostali 404. Dobrze czy nie ? ------------------ Szereg strza³ów z adresów: 96.254.171.2, 62.236.108.240, 80.82.64.227 gdzie albo tekst by³ szyfrowany, albo to jaki¶ ¶mietnik jest. Same robaki. Albo same entery. Nic sensownego. Znaków od kilku do kilkunastu conajwy¿ej. Próbuje je zrozumieæ, i te robaki NOTEPAD++ rozkodowuje mniej wiêcej na symbole (tu jedno przyk³adowe ¿±danie, rozdzielam symbole znakiem |): EOT|SOH|NUL|P????NUL Te ? ju¿ z zakresu drukowalnego, ale chyba powy¿ej 128. Có¿ to za wywo³ania? Te znaki s± ró¿ne w ró¿nych wywo³aniach. Wystêpowa³y w krótkich seriach, czyli wygl±da³o to na jak±¶ próbê nawi±zania porozumienia lub negocjacjê. Nie wiedz±c jak zareagowaæ, serwer odpowiada³ 400 Bad Request. Czego wo³aj±cy chcieli ? ------------------ I chyba najciekawsze, 2 razy, ( po 3 dniach 2 raz) z adresu 198.100.145.163: GET http://www.google.com/ HTTP/1.0 Host: www.google.com Accept: text/html User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Proxy-Connection: close i raz z adresu 77.253.247.100: GET http://www.google.pl/search?hl=pl&q=blog HTTP/1.1 Host: www.google.pl User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Accept: */* Accept-Language: zh-cn Connection: Keep-Alive Czyli co¶ od googla. Ale serwer oczekuje bardo konkretnego wywo³ania, i spodziewa³ siê, ¿e jak klient zadzia³a w ciemno, to poprosi "GET /", a nie GET z jak±¶ domen± w pierwszej linii. Natomiast w polu host spodziewa³em siê domeny z któr± klient chce rozmawiaæ. W zwi±zku z tym w odpowiedzi dosta³y 404 not found. Ale googla powinno siê chyba lepiej potraktowaæ - ale co mu odpowiedzieæ ? Spróbuj 303 index.html ? Ale z jakiej domeny ? Dla wywo³ania "GET /" po IPv4 a nie konkretnej domeny serwer przygotowuje stronkê z list± obs³ugiwanych domen. Ale co odpowiedzieæ w takim przypadku ? Czy traktowaæ googla inaczej ni¿ gameframe.net ? Nie gram w ¿adne gry - czego kto¶ siê dobija i w jakiej sprawie ? ------------------ Widzê jeszcze, ¿e zdarza siê ( i to m.in. od google.com!) HTTP/1.0, a ja my¶la³em, ¿e to dawno is dead. Widzê, ¿e serwer jak dostanie HTTP/1.0 to nieraz te¿ odpowiada HTTP/1.0, ale 400 Bad Request odpowiada HTTP/1.1. Ale w jakie¶ wiêksze ró¿nice pomiêdzy 1.0 a 1.1 wewnêtrznie serwer nie wchodzi. Za³o¿y³em, ¿e w erze cyfryzacji TV i nied³ugo radia, HTTP/1.0 nikt nie u¿ywa. A tu google.com - czy to powa¿ny b³±d brak rozró¿nienia na HTTP/1.0 i HTTP/1.1 ? Pozdrawiam, Marek Horodyski
Re: Dziwne requesty
Author: Grzegorz Staniak
Date: Sat, 03 Aug 2013 14:44
Date: Sat, 03 Aug 2013 14:44
54 lines
1940 bytes
1940 bytes
On 03.08.2013, marek.horodyski@gmail.com <marek.horodyski@gmail.com> wrote: > Dobry wieczór :) > Startuję z serwowaniem www. Na razie nie mam czasu coś więcej stworzyć, > ale serwer stoi i takie puste strony może wystawić. Stoi se i "słucha", > a tu takie niespodziewane wołania się pojawiają, co do obsługi których > mam szereg wątpliwości i w związku z tym pytań : Chyba powinieneś przeczytać specyfikację HTTP (RFC 2616) zanim napiszesz ten serwer. I ty będziesz więcej wiedział o tym jak się serwer powinien zachowywać, i klienty nie będą zaskakiwane "dziwnymi" reakcjami serwera. > GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1 Skanowanie w poszukiwaniu dziur w oprogramowaniu serwera: http://nfsec.pl/security/199 > GET / HTTP/1.0 HTTP w wersji 1.0 nie wymagał nagłówka "Host". Powinieneś podać odpowiedź z domyślnego wirtualnego hosta dla danej instalacji. > CONNECT tcpconn2.tencent.com:443 HTTP/1.1 > GET http://server5.cyberpods.net/azenv.php HTTP/1.1 > GET http://gameframe.net/headers HTTP/1.1 Ktoś usiłuje użyć cię jako proxy/proxy SSL. Niekoniecznie w uczciwych zamiarach. > GET http://www.google.com/ HTTP/1.0 > Host: www.google.com > Accept: text/html > User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) > Proxy-Connection: close > > GET http://www.google.pl/search?hl=pl&q=blog HTTP/1.1 > Host: www.google.pl > > Czyli coś od googla. _Do_ googla. Nagłówek "Host" zawiera nazwę domenową vhosta z którego klient chce pobrać dokumenty pod danym adresem IP. Znowu próba użycia proxy. W pierwszym przypadku masz nawet świadczący o tym nagłówek (Proxy-Connection). Jeśli nie lubisz czytać specyfkacji technicznych, znajdź jakąś książkę, coś podobnego do: http://www.amazon.com/dp/0471398233 -- ale z jakimś opisem HTTP powinieneś się zapoznać, skoro chcesz go obsługiwać. GS -- Grzegorz Staniak <gstaniak _at_ gmail *dot* com>
Re: Dziwne requesty
Author: marek.horodyski@
Date: Sat, 03 Aug 2013 19:37
Date: Sat, 03 Aug 2013 19:37
92 lines
3465 bytes
3465 bytes
W dniu sobota, 3 sierpnia 2013 16:44:47 UTC+2 u¿ytkownik Grzegorz Staniak napisa³:
> On 03.08.2013, marek.horodyski@gmail.com <marek.horodyski@gmail.com> wrote:
>
>
[...]
> Chyba powiniene¶ przeczytaæ specyfikacjê HTTP (RFC 2616) zanim
>
> napiszesz ten serwer. I ty bêdziesz wiêcej wiedzia³ o tym jak siê
>
> serwer powinien zachowywaæ, i klienty nie bêd± zaskakiwane "dziwnymi"
Witam,
Próbowa³em to czytaæ. W wielu RFC nie wiedz± jak pisaæ zwiê¼le. Mo¿e jakie¶ bryki by siê przyda³y? Jestem ³adnie 55+ i mam ¶wiadomo¶æ, ¿e próbuj±c zaczynaæ od RFC, z czego mo¿e 4% by³o by mi przydatne, nigdy bym nie dotar³ do koñca. Nie zd±¿y³ bym :). I tak mi bardzo wolno idzie. Ale jak na razie dzia³a to co chcê aby dzia³a³o, hostowanie kilku domen te¿. Przy czym w³a¶nie z wiersza HOST sprawdzam do jakiej domeny jest odwo³anie - st±d to moje zaskoczenie, jak w tym polu "google" siê pojawi³o. Nie wiem jeszcze jak rozpoznaæ w tych wywo³aniach zapytania indeksuj±ce wyszukiwarek. Tych dziwnych requestów jest do¶æ du¿o. Ostatnio najwiêcej jest prób wydobycia jakich¶ plików SETUP o ró¿nych nazwach i próbach umiejscowienia. Np. :
GET /php-my-admin/scripts/setup.php HTTP/1.1
GET /phpMyAdmin-2/scripts/setup.php HTTP/1.1
GET /phpMyAdmin-2.5.5/index.php HTTP/1.1
GET /mysqladmin/ HTTP/1.1
GET /pma/scripts/setup.php HTTP/1.1
...
Dostaj± grzecznie w odpowiedzi 404 i ju¿. Jak by lepiej odpowiedzi czyta³y to by wiedzia³y, ¿e server nie jest na php i nie ma czego szukaæ.
> HTTP w wersji 1.0 nie wymaga³ nag³ówka "Host". Powiniene¶ podaæ
>
> odpowied¼ z domy¶lnego wirtualnego hosta dla danej instalacji.
Przy CONNECT nie poda³ HOST. Ca³y nag³ówek to :
CONNECT www.google.com:443 HTTP/1.0
ale przy GET 1.0 jest :
GET http://www.google.com/ HTTP/1.0
Host: www.google.com
Accept: text/html
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Proxy-Connection: close
Czy to by³ jaki¶ boot z google ?
Odpowied¼ by³a :
HTTP/1.0 404 Not Found
X-Powered-By: Harbour 3.2.0dev (r1304301343)/MinGW GNU C 4.6.1 (32-bit)
Cache-Control: no-cache
Server: homar.exe
Content-Type: text/html
Connection: Keep-Alive
Keep-Alive: timeout=15
Date: Fri, 02 Aug 2013 23:34:39 GMT
Content-Length: 52
<html><body><h1>404 Not Found<br></h1></body></html>
Gdyby w HOST by³ sformatowany w IPv4 ( adres serwera) a po GET by³ by znak "/", w odpowiedzi posz³a by lista domy¶lnych domen. Pisz±c "domy¶lnego wirtualnego hosta dla danej instalacji" mia³e¶ chyba co¶ takiego na my¶li, tylko chodzi³o zapewne o jedn± domenê. Jak w takim przypadku powinien wygl±daæ komunikat odpowiedzi? Chodzi mi o poprawn± obs³ugê requestu przys³anego w pozytywnych/rozpoznawczych ("pokojowych") zamiarach. To mo¿e byæ jaka¶ jedna g³ówna domena. O ile komunikacjê serwera po HTTP z przegl±dark± mogê przetestowaæ, to jak po drugiej stronie jest co¶ innego, mam trochê "zwi±zane rêce".
> > GET http://www.google.pl/search?hl=pl&q=blog HTTP/1.1
> > Host: www.google.pl
> > Czyli co¶ od googla.
>
> _Do_ googla. Nag³ówek "Host" zawiera nazwê domenow± vhosta z którego
Do googla ? Czy to by³o z jakiego¶ wyszukiwania googlowego ?
Pozdrawiam,
Marek Horodyski
Re: Dziwne requesty
Author: Grzegorz Staniak
Date: Sun, 04 Aug 2013 17:07
Date: Sun, 04 Aug 2013 17:07
42 lines
1673 bytes
1673 bytes
On 04.08.2013, marek.horodyski@gmail.com <marek.horodyski@gmail.com> wrote: >> Chyba powinieneś przeczytać specyfikację HTTP (RFC 2616) zanim >> napiszesz ten serwer. I ty będziesz więcej wiedział o tym jak się >> serwer powinien zachowywać, i klienty nie będą zaskakiwane "dziwnymi" > > Witam, > Próbowałem to czytać. W wielu RFC nie wiedzą jak pisać zwięźle. E tam. Całość specyfikacji protokołu na ~100 stronach to wcale nie jest dużo. To nie jest gęsta proza, tylko techniczny opis. Bez tego, niestety, będziesz obsługiwał HTTP na oślep, wedle znanej metody profesora Macajewa. Ani tobie, ani klientom korzystającym z twojego serwera nie wyjdzie to na dobre. > GET /php-my-admin/scripts/setup.php HTTP/1.1 > GET /phpMyAdmin-2/scripts/setup.php HTTP/1.1 > GET /phpMyAdmin-2.5.5/index.php HTTP/1.1 > GET /mysqladmin/ HTTP/1.1 > GET /pma/scripts/setup.php HTTP/1.1 Macają w poszukiwaniu dziur. Szukanie nie zabezpieczonych po instalacji phpmysqladmina plików "setup.php", albo w ogóle instalacji, na której można by testować exploity. [...] >> > GET http://www.google.pl/search?hl=pl&q=blog HTTP/1.1 >> > Host: www.google.pl >> > Czyli coś od googla. >> >> _Do_ googla. Nagłówek "Host" zawiera nazwę domenową vhosta z którego > > Do googla ? Czy to było z jakiegoś wyszukiwania googlowego ? _DO_ googla. Za pośrednictwem twojego serwera. Ot, taki test czy przypadkiem nie trafi się źle skonfigurowane proxy. Wyszukiwanie guglowe to byłoby zapytanie robota google o dokumenty z twojego serwisu, a nie próba pobrania strony głównej Google Search, prawda? GS -- Grzegorz Staniak <gstaniak _at_ gmail *dot* com>
Re: Dziwne requesty
Author: marek.horodyski@
Date: Sun, 04 Aug 2013 17:40
Date: Sun, 04 Aug 2013 17:40
49 lines
2399 bytes
2399 bytes
W dniu niedziela, 4 sierpnia 2013 19:07:38 UTC+2 u¿ytkownik Grzegorz Staniak napisa³: [...] > E tam. Ca³o¶æ specyfikacji protoko³u na ~100 stronach to wcale nie > jest du¿o. To nie jest gêsta proza, tylko techniczny opis. Bez tego, > niestety, bêdziesz obs³ugiwa³ HTTP na o¶lep, wedle znanej metody > profesora Macajewa. Ani tobie, ani klientom korzystaj±cym z twojego > serwera nie wyjdzie to na dobre. Z powietrza pomys³u nie wzi±³em. Wykorzystujê podstawy dzia³aj±cego serwera napisanego przez Mindaugasa Kavaliauskasa ( dbtopas at dbtopas dot lt). On siê jako¶ przez RFC przebi³. Widaæ m³ody i zdolny. Dzia³aj±cy, wielow±tkowy serwer z obs³ug± domen w Harbour ma teraz 560 linni, 26 kb. Przeliczaj±c 3,5 kilo na stronê, wyjdzie 7,5 strony. Jak to siê ma do 132 "prozy" ? Zaczynaj±c przegl±da³em wiele ró¿nych materia³ów, te¿ RFC. Chyba 132 strony i niestety nie mog³em tam znale¼æ odpowiedzi na moje pytania/w±tpliwo¶ci, i bez irytacji, wiêcej korzy¶ci mia³em z testów i przegl±dania innych kodów ni¿ RFC (czyli na macajewa :). Co prawda serwer obs³uguje tylko GET i POST oraz bêdê chcia³ dopisaæ jeszcze PUT. Nie obs³uguje HTTPS, i nie wiem czy bêdzie. To raczej poza moimi potrzebami. > Macaj± w poszukiwaniu dziur. Szukanie nie zabezpieczonych po instalacji > phpmysqladmina plików "setup.php", albo w ogóle instalacji, na której > mo¿na by testowaæ exploity. Dopóki php w wywo³aniach, dopóty mogê spaæ spokojnie :) > _DO_ googla. Za po¶rednictwem twojego serwera. Ot, taki test czy > przypadkiem nie trafi siê ¼le skonfigurowane proxy. Wyszukiwanie > guglowe to by³oby zapytanie robota google o dokumenty z twojego serwisu, > a nie próba pobrania strony g³ównej Google Search, prawda? Proxy to ju¿ wiêksza rzecz, a tu cienki serwerek na cienkim ³±czu. Nie znajd± czego¶, czego nie ma. W sumie przygl±dam siê tym wywo³aniom, i widzê, ¿e tak wygl±da real. Trzeba siê przyzwyczaiæ a nie dziwiæ :) No nic, czytam teraz o SMTP, POP3, IMAPach itp. Ró¿nych ksi±¿ek, eBooków na ró¿ne tematy pozaczynane, a tu kolejny pomys³y nêkaj±. Im wiêcej czytam, tym wiêcej ustawia siê w kolejce do przeczytania ... Pozdrawiam, Marek Horodyski
Re: Dziwne requesty
Author: marek.horodyski@
Date: Mon, 05 Aug 2013 16:24
Date: Mon, 05 Aug 2013 16:24
72 lines
2535 bytes
2535 bytes
W dniu niedziela, 4 sierpnia 2013 19:07:38 UTC+2 użytkownik Grzegorz Staniak napisał:
[...]
Witam ponownie.
Próbuję wykorzystać RFC. Miałem żądanie :
HEAD / HTTP/1.0
z adresu 194.87.34.22. Odpowiedziałem :
HTTP/1.0 501 Not Implemented
X-Powered-By: Harbour 3.2.0dev (r1304301343)/MinGW GNU C 4.6.1 (32-bit)
Cache-Control: no-cache
Server: homar.exe
Content-Type: text/html
Connection: Close
Keep-Alive: timeout=15
Date: Mon, 05 Aug 2013 08:54:25 GMT
Content-Length: 58
<html><body><h1>501 Not Implemented<br></h1></body></html>
Wg RFC powiniem odpowiedzieć :
HEAD
The HEAD method is identical to GET except that the server MUST NOT
return a message-body in the response. The metainformation contained
in the HTTP headers in response to a HEAD request SHOULD be identical
to the information sent in response to a GET request. This method can
be used for obtaining metainformation about the entity implied by the
request without transferring the entity-body itself. This method is
often used for testing hypertext links for validity, accessibility,
and recent modification.
The response to a HEAD request MAY be cacheable in the sense that the
information contained in the response MAY be used to update a
previously cached entity from that resource. If the new field values
indicate that the cached entity differs from the current entity (as
would be indicated by a change in Content-Length, Content-MD5, ETag
or Last-Modified), then the cache MUST treat the cache entry as
stale.
Problem w tym, że RFC nie podaje przykładowego żądania i poprawnej nań odpowiedzi, czego mi najbardziej brakuje. Wygląda, że odpowiedź powinna wyglądać :
HTTP/1.0 200 OK
X-Powered-By: Harbour 3.2.0dev (r1304301343)/MinGW GNU C 4.6.1 (32-bit)
Cache-Control: no-cache
Server: homar.exe
Content-Type: text/html
Connection: Close
Keep-Alive: timeout=15
Date: Mon, 05 Aug 2013 08:54:25 GMT
Content-Length: 0
albo przynajmniej tak mi się wydaje. Wobec tego dopisałem w kodzie metodę :
switch server[ as_http[ 10]]
case "HEAD"
exit // powinno pójść domyślne 200 w odpowiedzi i pusta strona - do TESTU!
case "GET"
case "POST"
I teraz ważne pytanie : JAK TO PRZETESTOWAĆ ?
Jak ze strony klienta wygenerować takie żądanie, abym mógł sprawdzić co serwer zrobi ?
Pozdrawiam,
Marek Horodyski
Re: Dziwne requesty
Author: Grzegorz Staniak
Date: Tue, 06 Aug 2013 01:54
Date: Tue, 06 Aug 2013 01:54
83 lines
2847 bytes
2847 bytes
On 05.08.2013, marek.horodyski@gmail.com <marek.horodyski@gmail.com> wrote: > Wg RFC powiniem odpowiedzieć : > HEAD > > The HEAD method is identical to GET except that the server MUST NOT > return a message-body in the response. The metainformation contained > in the HTTP headers in response to a HEAD request SHOULD be identical > to the information sent in response to a GET request. This method can > be used for obtaining metainformation about the entity implied by the > request without transferring the entity-body itself. This method is > often used for testing hypertext links for validity, accessibility, > and recent modification. > > The response to a HEAD request MAY be cacheable in the sense that the > information contained in the response MAY be used to update a > previously cached entity from that resource. If the new field values > indicate that the cached entity differs from the current entity (as > would be indicated by a change in Content-Length, Content-MD5, ETag > or Last-Modified), then the cache MUST treat the cache entry as > stale. > > Problem w tym, że RFC nie podaje przykładowego żądania i poprawnej nań > odpowiedzi, czego mi najbardziej brakuje. Przecież będą dokładnie takie same jak dla GET, tylko bez wysyłania treści zasobu. > Wygląda, że odpowiedź powinna wyglądać : > > HTTP/1.0 200 OK > X-Powered-By: Harbour 3.2.0dev (r1304301343)/MinGW GNU C 4.6.1 (32-bit) > Cache-Control: no-cache > Server: homar.exe > Content-Type: text/html > Connection: Close > Keep-Alive: timeout > Date: Mon, 05 Aug 2013 08:54:25 GMT > Content-Length: 0 Content-length albo podajesz takie "jakie by było" gdybyś wysyłał treść, albo omijasz (np. dla zasobów generowanych dynamicznie, dla których nie może być z góry znane). Czyli nie "0". > albo przynajmniej tak mi się wydaje. Wobec tego dopisałem w kodzie metodę : > > switch server[ as_http[ 10]] > case "HEAD" > exit // powinno pójść domyślne 200 w odpowiedzi i pusta strona - do TESTU! > case "GET" > case "POST" > > I teraz ważne pytanie : JAK TO PRZETESTOWAĆ ? > Jak ze strony klienta wygenerować takie żądanie, abym mógł sprawdzić > co serwer zrobi ? A choćby i ręcznie: [~]$ telnet www.onet.pl 80 Trying 213.180.141.140... Connected to www.onet.pl. Escape character is '^]'. HEAD / HTTP/1.1 Host: www.onet.pl Connection: close HTTP/1.1 200 OK server: edgeserver content-length: 117325 content-type: text/html; charset=utf-8 cache-control: private pragma: no-cache Connection: close Connection closed by foreign host. Albo poszukaj sobie jakiegoś narzędzia, np. czegoś stąd: http://stackoverflow.com/questions/1976442/how-do-i-send-a-head-request-manually-using-firefox GS -- Grzegorz Staniak <gstaniak _at_ gmail *dot* com>
Re: Dziwne requesty
Author: marek.horodyski@
Date: Tue, 06 Aug 2013 17:02
Date: Tue, 06 Aug 2013 17:02
32 lines
834 bytes
834 bytes
W dniu wtorek, 6 sierpnia 2013 03:54:35 UTC+2 u¿ytkownik Grzegorz Staniak napisa³: [...] > Content-length albo podajesz takie "jakie by by³o" gdyby¶ wysy³a³ tre¶æ, > > albo omijasz (np. dla zasobów generowanych dynamicznie, dla których > > nie mo¿e byæ z góry znane). Czyli nie "0". Ok. Z opisu RFC takich rzeczy w³a¶nie siê nie mogê dowiedzieæ. > A choæby i rêcznie: > > > > [~]$ telnet www.onet.pl 80 No w³a¶nie, przeskanowa³em dysk i mam tylko : c:\Windows\winsxs\amd64_microsoft-windows-telnet-client_31bf3856ad364e35_6.1.7600.16385_none_1426830c3ebb712d\telnet.exe To chyba nie do u¿ycia. A kompa z Mintem akurat znajomy po¿yczy³ na kilka dni. Wrócê do tych testów i w±tku za jakie¶ 1,5 - 2 tygodnie. Pozdrawiam, Marek Horodyski
Re: Dziwne requesty
Author: Grzegorz Staniak
Date: Wed, 07 Aug 2013 08:03
Date: Wed, 07 Aug 2013 08:03
50 lines
1669 bytes
1669 bytes
On 07.08.2013, marek.horodyski@gmail.com <marek.horodyski@gmail.com> wrote:
> [...]
>
>> Content-length albo podajesz takie "jakie by było" gdybyś wysyłał treść,
>> albo omijasz (np. dla zasobów generowanych dynamicznie, dla których
>> nie może być z góry znane). Czyli nie "0".
>
> Ok. Z opisu RFC takich rzeczy właśnie się nie mogę dowiedzieć.
Taaa ;)
14.13 Content-Length
The Content-Length entity-header field indicates the size of the
entity-body, in decimal number of OCTETs, sent to the recipient or,
in the case of the HEAD method, the size of the entity-body that
would have been sent had the request been a GET.
Content-Length = "Content-Length" ":" 1*DIGIT
An example is
Content-Length: 3495
Applications SHOULD use this field to indicate the transfer-length
of the message-body, unless this is prohibited by the rules in
section 4.4.
[...]
4.4 Message Length
The transfer-length of a message is the length of the
message-body as it appears in the message; that is, after any
transfer-codings have been applied. When a message-body is included
with a message, the transfer-length of that body is determined by one
of the following (in order of precedence):
[...]
> c:\Windows\winsxs\amd64_microsoft-windows-telnet-client_31bf3856ad364e35_6.1.7600.16385_none_1426830c3ebb712d\telnet.exe
>
> To chyba nie do użycia.
Można ściągnąć choćby i puTTY, telnet też obsłuży. Poza tym,
windowsowy telnet też powinien rozpoznać argument w postaci numeru
portu. No i zawsze są np. dodatki do Firefoksa.
GS
--
Grzegorz Staniak <gstaniak _at_ gmail *dot* com>
Re: Dziwne requesty
Author: dot
Date: Fri, 09 Aug 2013 20:25
Date: Fri, 09 Aug 2013 20:25
13 lines
777 bytes
777 bytes
marek.horodyski@gmail.com pisze: > W dniu niedziela, 4 sierpnia 2013 19:07:38 UTC+2 użytkownik Grzegorz Staniak napisał: > [...] > I teraz ważne pytanie : JAK TO PRZETESTOWAĆ ? > Jak ze strony klienta wygenerować takie żądanie, abym mógł sprawdzić co serwer zrobi ? stosownymi narzędziami rozumiejącymi HTTP: wget --header="..." ... http[s]://example.org/path/to/file?... curl --header="..." ... http[s]://example.org/path/to/file?... (za pomocą curla zrobisz nawet PUT, DELETE, być może nawet OPTIONS?) ewentualnie bardziej hard (bez zbędnego kodowania w C) perl IO::Socket IO::Socket::INET->new() i w dosyć łatwy, prosty i zautomatyzowany sposób wyślesz dowolnie spreparowanego / wygenerowanego requesta niezbędnego do testów danej funkcjonalności ...
Re: Dziwne requesty
Author: Grzegorz Staniak
Date: Sat, 10 Aug 2013 15:00
Date: Sat, 10 Aug 2013 15:00
34 lines
1247 bytes
1247 bytes
On 10.08.2013, Marek <precz@spamowi.com> wrote:
>>>> Content-length albo podajesz takie "jakie by było" gdybyś wysyłał treść,
>>>> albo omijasz (np. dla zasobów generowanych dynamicznie, dla których
>>>> nie może być z góry znane). Czyli nie "0".
>>>
>>> Ok. Z opisu RFC takich rzeczy właśnie się nie mogę dowiedzieć.
>>
>> Taaa ;)
>>
>> 14.13 Content-Length (...)
> >
>
> > Applications SHOULD use this field to indicate the transfer-length
> > of the message-body, unless this is prohibited by the rules in
> > section 4.4.
>
> Szczerze mówiąc ja też nie widzę w cytowanym przez Ciebie fragmencie, że
> nagłówek można pominąć dla dynamicznych treści.
Nie chciałem spamować cytując całe strony. Jest trochę dalej w 14.13:
In HTTP, it SHOULD be sent whenever the message's length can be
determined prior to being transferred, unless this is prohibited
by the rules in section 4.4.
Innymi słowy, należy stosować reguły z 4.4 i wysyłać "Content-length"
zawsze, kiedy da się tę długość ustalić. A przypadki kiedy nie można
jest z wyprzedzeniem ustalić to właśnie najczęściej treść generowana
dynamicznie.
GS
--
Grzegorz Staniak <gstaniak _at_ gmail *dot* com>
Re: Dziwne requesty
Author: Grzegorz Staniak
Date: Sat, 10 Aug 2013 16:10
Date: Sat, 10 Aug 2013 16:10
24 lines
948 bytes
948 bytes
On 10.08.2013, Sylwester Zarębski <zbieracz@isp.net.pl> wrote: >> > Applications SHOULD use this field to indicate the transfer-length >> > of the message-body, unless this is prohibited by the rules in >> > section 4.4. >> Moim zdaniem "powinna" = "musi" moim zdaniem, a użyto "powinna" >> bo nikt za brak tego nagłówka głowy nie obetnie. > > Nie, nie. "SHOULD" = "powinna" oznacza dokładnie tyle, czyli dobrze by > było, ale niekoniecznie. > "MUST" = "musi być" oznacza też dokładnie tyle, czyli nagłówek jest > wymagany, w przeciwnym razie łamie RFC (co oznacza, że zgodne z RFC > aplikacje nie będą działać poprawnie ze stroną łamiącą RFC). > > Nie przeglądałem tego konkretnie RFC, ale w wielu jest wyjaśnienie co > dokładnie oznacza SHOULD, MUST, MUST NOT, etc. Jest już na ten temat oddzielne RFC :) http://www.ietf.org/rfc/rfc2119.txt GS -- Grzegorz Staniak <gstaniak _at_ gmail *dot* com>
Re: Dziwne requesty
Author: Marek
Date: Sat, 10 Aug 2013 16:26
Date: Sat, 10 Aug 2013 16:26
28 lines
1081 bytes
1081 bytes
W dniu 2013-08-07 10:03, Grzegorz Staniak pisze: >>> Content-length albo podajesz takie "jakie by było" gdybyś wysyłał treść, >>> albo omijasz (np. dla zasobów generowanych dynamicznie, dla których >>> nie może być z góry znane). Czyli nie "0". >> >> Ok. Z opisu RFC takich rzeczy właśnie się nie mogę dowiedzieć. > > Taaa ;) > > 14.13 Content-Length (...) > > Applications SHOULD use this field to indicate the transfer-length > of the message-body, unless this is prohibited by the rules in > section 4.4. Szczerze mówiąc ja też nie widzę w cytowanym przez Ciebie fragmencie, że nagłówek można pominąć dla dynamicznych treści. Tu napisano, że aplikacja powinna używać tego nagłówka z wyjątkiem sytuacji gdy jest to niedozwolone (o czym sekcja 4.4 informuje). Moim zdaniem "powinna" = "musi" moim zdaniem, a użyto "powinna" bo nikt za brak tego nagłówka głowy nie obetnie. Najwyżej wiadomość np. nie zostanie odebrana poprawnie. Skąd wniosek, że można zignorować wysyłanie nagłówka? -- Pozdrawiam Marek
Re: Dziwne requesty
Author: Sylwester =?iso-
Date: Sat, 10 Aug 2013 17:20
Date: Sat, 10 Aug 2013 17:20
23 lines
898 bytes
898 bytes
Dnia Sat, 10 Aug 2013 16:26:59 +0200, Marek napisa³(a): > W dniu 2013-08-07 10:03, Grzegorz Staniak pisze: > > Applications SHOULD use this field to indicate the transfer-length > > of the message-body, unless this is prohibited by the rules in > > section 4.4. > Moim zdaniem "powinna" = "musi" moim zdaniem, a u¿yto "powinna" > bo nikt za brak tego nag³ówka g³owy nie obetnie. Nie, nie. "SHOULD" = "powinna" oznacza dok³adnie tyle, czyli dobrze by by³o, ale niekoniecznie. "MUST" = "musi byæ" oznacza te¿ dok³adnie tyle, czyli nag³ówek jest wymagany, w przeciwnym razie ³amie RFC (co oznacza, ¿e zgodne z RFC aplikacje nie bêd± dzia³aæ poprawnie ze stron± ³ami±c± RFC). Nie przegl±da³em tego konkretnie RFC, ale w wielu jest wyja¶nienie co dok³adnie oznacza SHOULD, MUST, MUST NOT, etc. -- pozdrawiam Sylwester Zarêbski Aby wys³aæ email zmieñ zbieracz w adresie na sylwek
Re: Dziwne requesty
Author: Marek
Date: Tue, 13 Aug 2013 22:40
Date: Tue, 13 Aug 2013 22:40
35 lines
1382 bytes
1382 bytes
W dniu 2013-08-10 17:00, Grzegorz Staniak pisze: > > Nie chciałem spamować cytując całe strony. Jest trochę dalej w 14.13: To nie jest żadne spamowanie :-) Znalazłem fragment w 14.13, który to faktycznie opisuje. To co cytujesz poniżej oznacza zupełnie coś innego - stąd moje niezrozumienie. Tak czy owak nie dziw się mojemu imiennikowi, że nie wyczytał interpretacji nagłówka z RFC bo jest to tak zredagowane, że trzeba mocno się skupiać aby doczytać w czym rzecz. > In HTTP, it SHOULD be sent whenever the message's length can be > determined prior to being transferred, unless this is prohibited > by the rules in section 4.4. > > Innymi słowy, należy stosować reguły z 4.4 i wysyłać "Content-length" > zawsze, kiedy da się tę długość ustalić. A przypadki kiedy nie można > jest z wyprzedzeniem ustalić to właśnie najczęściej treść generowana > dynamicznie. No właśnie tak nie można tego przetłumaczyć :-) "...unless this is prohibited by the rules in section 4.4" oznacza - ...z wyjątkiem sytuacji kiedy dołączanie nagłówka content-length jest niedozwolone w przypadkach opisanych w sekcji 4.4 (czyli tam, gdzie body wiadomości nie występuje). Przy okazji ta sekcja wyjaśnia jak policzyć rozmiar body gdy w/w nagłówek nie został podany - ale to już inna para kaloszy. -- Pozdrawiam Marek
Re: Dziwne requesty
Author: Grzegorz Staniak
Date: Sat, 17 Aug 2013 00:27
Date: Sat, 17 Aug 2013 00:27
31 lines
1327 bytes
1327 bytes
On 13.08.2013, Marek <precz@spamowi.com> wrote: >> In HTTP, it SHOULD be sent whenever the message's length can be >> determined prior to being transferred, unless this is prohibited >> by the rules in section 4.4. >> >> Innymi słowy, należy stosować reguły z 4.4 i wysyłać "Content-length" >> zawsze, kiedy da się tę długość ustalić. A przypadki kiedy nie można >> jest z wyprzedzeniem ustalić to właśnie najczęściej treść generowana >> dynamicznie. > > No właśnie tak nie można tego przetłumaczyć :-) > > "...unless this is prohibited by the rules in section 4.4" > > oznacza - ...z wyjątkiem sytuacji kiedy dołączanie nagłówka > content-length jest niedozwolone w przypadkach opisanych w sekcji 4.4 > (czyli tam, gdzie body wiadomości nie występuje). To nie było tłumaczenie, tylko skrót: a) stosować 4.4, b) a poza tym, wysyłać nagłówek wtedy kiedy da się ustalić długość treści dokumentu. To nadal daje opis poprawnego stosowania tego nagłówka. Język RFC można krytykować, ale jednak da się z nich wyczytać w sumie wszystko, co trzeba wiedzieć, żeby poprawnie stosować HTTP. I to jest instancja, litera RFC zawsze ma pierwszeństwo przed domysłami i na nich opartymi interpretacjami. GS -- Grzegorz Staniak <gstaniak _at_ gmail *dot* com>
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads