Od RFC2616 Sec4.2:
Każdy nagłówek pole składa się z nazwy a następnie dwukropek (":") oraz wartości pola.
Na pierwszy rzut oka wydawałoby się, że umieszcza wiadomości, które określają puste wartości nagłówków w źle skonstruowanej, niezgodnej kategorii. Jednak zwiększona forma BNF nakreślono w RFC2616 Sec2.1 wskazuje
„#element” pozwala na dowolną liczbę, włącznie zera
Ponieważ jest to deklaracja używany do określenia wartości nagłówka Accept, wydaje się, że puste wartości są ważne.
analizowania pustych nagłówki i nagłówki z białych spacji może być problematyczne, ponieważ należy do kierunku od specyfikacji:
pole, zawartość nie zawiera żadnych początkowych lub końcowe LWS: liniowa białej przestrzeni występującej zanim pierwszy nieliniowy znak wartości pola lub po ostatnim nieliniowym znaku wartości pola . Takie wiodące lub końcowe LWS MOGĄ być usuwane bez zmiany semantyki wartości pola. Każde LWS występujące pomiędzy polem o treści MOŻE zostać zastąpione pojedynczym SP przed interpretacją wartości pola lub przesłaniem komunikatu poniżej.
IMHO, wysłanie pustego nagłówka jest całkowicie bezsensowne. Nie powinno się tego robić, a parsery mogą nieprawidłowo analizować te nagłówki.Tradycyjnie, ludzie, którzy chcą obejść te ograniczenia, gdy do czynienia z elementów niezgodnych określono wartości „pseudo-empty” tak:
X-MyCustomHeader: ""
Jeśli chcesz po prostu potwierdzić, że pole nagłówka został wysłany jako część w postaci przełącznika boolowskiego, rozważ wysyłanie wartości zastępczej, jak wyżej, zamiast pustej wartości.
Aktualizacja
Chyba nie było bardzo jasne, bezpośrednio odpowiadając na pytanie: w przypadku pustego nagłówka Accept naprawdę masz dwie opcje:
- Wyślij
406 Not Acceptable odpowiedź, aby poinformować klienta, że nie oferuje żadnych typów zawartości dla pustej wartości Accept (duh).
to jest uzasadnione, ale nie jest to wymagane RFC2616 Sec14.1:
Jeśli pole Zebrane nagłówek jest obecne, a serwer nie może wysłać odpowiedź które są akceptowalne według nomenklatury Accept pola wartością , wtedy serwer POWINIEN wysłać odpowiedź 406 (nieakceptowalną).
- Albo, ponieważ nie jest to wymagane i jest to bardzo mało prawdopodobne, że użytkownik nie akceptuje żadnych rodzajów treści (w przeciwnym razie, dlaczego mieliby przejmować wysłać wniosek?) ... Proponuję traktowanie pustej wartości
Accept: (jeśli odrzucanie wiadomości nie jest opcją) jest takie samo jak Accept: */*.
Nie zgadzam się z pustymi nagłówkami, które są zniekształcone, zwłaszcza że sama specyfikacja odnosi się do pustych nagłówków (zobacz mój przykład Accept-Encoding). Aby nadać kontekst, rozwijam oprogramowanie pośredniczące Pythona i zastanawiam się nad ewentualnymi i testuję je. Poszedłem do założenia '' */* '', które wydaje mi się rozsądne. Dzięki za poświęcenie czasu! –
Uważam także, że "400 Złych Zleceń" byłoby bardziej odpowiednie niż "Niedozwolone 406", przynajmniej jeśli założymy, że jest to naruszenie specyfikacji. W tym przypadku nie mogliśmy ustalić, co klient faktycznie akceptuje. –
Wiesz, masz rację co do 2616-2.1 - formularz '# element' wskazuje, że puste wartości nagłówków są w porządku. Zamierzam zaktualizować moją odpowiedź, aby to odzwierciedlić i uniknąć dezinformacji. Poza tym myślę, że powoduje to albo odpowiedź 406, albo też traktuje ją jak "Accept: */*". Ale prawdopodobnie nie jest to 400, ponieważ nie jest technicznie niepoprawną wiadomością. – rdlowrey