Thursday, December 18th, 2008...12:22 am

404 … a jednak prawidłowo

Jump to Comments

Cóż … lamowatego podejścia będzie ciąg dalszy. Wczoraj pisałem o błędzie 404 zwracanym przez IIS w przypadku, gdy odwołujemy się do strony ASP .NET a rozszerzenie to nie jest włączone. Wydawało mi sie to (i przyznam się że nadal tak mi sie wydaje) mało intuicyjne.

Jak jednak zwrócił mi uwagę Krzyś (popularnie kiedyś znany jako KMR 😉 ) takie zachowanie IIS jest jak najbardziej prawidłowe i zgodne z RFC (na które zresztą o ironio się sam powołałem). W RFC tym , w opisie błędu 403 czytamy:

(…)

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

(…)

Czyli sposób poinformowania klienta o problemie przez IIS jest jak najbardziej zgodny z RFC. Jak można przeczytać w komentarzach do poprzedniego posta IIS 7 robi to już całkowicie zgodnie z RFC:

(…) W starym iis6 komunikat byl jasny i mozna bylo latwo zrozumiec co jest nie tak, natomiast w ii7 mamy piekne 403 (…)

Czyli jak najbardziej poprawnie.

Wniosek …RTFRFC. Krzyś – dzięki za zwrócenie uwagi.

3 Comments

  • 404 jest odpowiedzią dla każdej sytuacji, w której serwer nie zna rozszerzenia pliku o który pytamy. Długo się o to potykałem… 😉

  • @Grzesio

    Uff … nie tylko ja, nie tylko ja … :). Tutaj sytuacja jest trochę inna jednak. System zna rozszerzenie jako takie, ponieważ ma je zarejestrowane do obsługi – w końcu dla .NET 1.1 je obsługuje :).

  • aha… no faktycznie wychodzi, że nie doczytałem.
    Ale przypomniało mi się za to, że 404 pojawia się też dla bibliotek ISAPI, dla których nie zezwolono na uruchamianie. Też ciekawostka 🙂

Leave a Reply