🚀 go-pugleaf

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>

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

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>

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

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

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=15
> 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>

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

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>

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 ...

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

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>

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

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>

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

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>