Pomieszany/zainspirowany komentarzem do mojego pytania Do search engines respect the HTTP header field “Content-Location”?, chciałbym wiedzieć, jaki jest dokładny cel Content-Location header field in HTTP i jak można go wykorzystać.Jaki jest cel pola nagłówka HTTP "Content-Location"?
W odpowiedzi na żądanie GET można użyć lokalizacji treści w HTTP, gdy żądany zasób ma wiele reprezentacji dostępnych, np. wiele języków. Wybór zwróconego zasobu zależy od nagłówków Accept w pierwotnym żądaniu GET.
Zazwyczaj lokalizacja podana w nagłówku Content-Location różni się od lokalizacji podanej w identyfikatorze URI pierwotnego żądania.
W odpowiedzi na żądanie POST lub PUT,
Section 14.14 of RFC 2616 stany:
Pole jednostka-nagłówek Content-lokalizacja może być użyty do podania lokalizacji zasobów dla podmiotu zamkniętym w komunikacie kiedy to jednostka dostępna jest z lokalizacji innej niż URI w poszukiwane zasobach ...
ta jest stosowana w AtomPub (RFC 5023, Section 9.2):
Jeżeli wniosek tworzenie zawierał dokument Atom wpis, a kolejna odpowiedź z serwera zawiera nagłówek Content-Location, spełniających nagłówku Location znak jakości do charakteru, wówczas klient jest upoważniony do interpretowania odpowiedzi podmiot jako pełna reprezentacja nowo utworzonego wpisu. Bez pasującego nagłówka Content-Location, klient NIE MOŻE założyć, że zwrócona jednostka jest kompletną reprezentacją utworzonego zasobu.
Należy pamiętać, że zachowanie opisane w AtomPub dotyczące kompletności reprezentacji nie jest poparte specyfikacją HTTP. – ordnungswidrig
Będzie to w httpbis: Część 2, Sekcja 6.1: http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-12.html#rfc.section.6.1 –
Należy pamiętać, że RFC2616 jest przestarzały przez RFC7231 i twój cytowany tekst nie jest już w RFC7231! Zobacz [Sekcja 3.1.4.2] (https://tools.ietf.org/html/rfc7231#section-3.1.4.2) – exhuma
sprawdź RFC2557 pod adresem: http://www.faqs.org/rfcs/rfc2557.html, aby uzyskać głębsze wyjaśnienie, jeśli jesteś zainteresowany. Obecnie piszę o tym dla klasy. Jest trochę stary, ale wciąż aktualny.
W RFC 2557 nie chodzi o zawartość HTTP-Location, o ile rozumiem. –
Nie jestem pewien, czy mówimy o tej samej rzeczy, ale RFC stwierdza: Ten dokument ... b) określa nagłówek treści MIME (Content-Location), który zezwala na identyfikatory URI w wieloczęściowym/pokrewnym tekście/html część ciała root w odniesieniu do zasobów pomocniczych w innych częściach ciała tej samej wieloczęściowej/powiązanej struktury. – seanAshmore
Z tego co wiem, dokument RFC 2557 dotyczy dokumentu zbiorczego, który zawiera wiele zasobów jako pojedynczy plik, a nagłówek "Lokalizacja treści" zasobu wewnątrz takiej kolekcji służy do określenia, który identyfikator URI może być używany do odnoszenia się do tego konkretnego zasobu. . Zagregowany typ dokumentu zdefiniowany w dokumencie RFC 2557 generalnie nie jest obsługiwany przez oprogramowanie znane jako przeglądarki WWW. Najbliższym dopasowaniem jest funkcja "Zapisz jako archiwum HTML" w programie Microsoft Internet Explorer. –
Nagłówek treści-lokalizacja HTTP ma zadeklarować unikalną lokalizację zasobu, który był użyty do odpowiedzi na HTTP GET (np. Żądanie było GET /frontpage HTTP/1.1, serwer może dodać nagłówek HTTP Content-Location: http://domain.com/frontpage.english.msie-optimized informujący klienta użytkownika, że jeśli ta konkretna odpowiedź jest potrzebna później, należy podać podaną lokalizację, ponieważ pierwotna lokalizacja może zależeć od różnych rzeczy, które powinny być wyjaśnione w nagłówku "Vary").
jednak pamiętać, że nagłówek HTTP Content-Lokalizacja jest problematyczne w czasie rzeczywistym zużycia światowego ponieważ różne przeglądarki (klienckie) poradzić inaczej: http://mail.python.org/pipermail/web-sig/2004-October/000985.html
Wynika to z RFC 2616 sekcji 14,14, który mówi, że „wartość Content-Location definiuje również podstawowy URI dla encji ". Krótko mówiąc, sprawny agent użytkownika oblicza adres URL BASE dla pobranego dokumentu za pomocą nagłówka Content-Location, co może skutkować użyciem różnych względnych adresów URL, jeśli pobrany dokument nie definiuje adresu URL BASE, a rzeczywisty pobrany adres i lokalizacja treści są wystarczająco różne (część "katalog"/"ścieżka" adresu URL jest inna).
Ponadto, nie widziałem jeszcze żadnej korzyści z używania HTTP Content-Location (miałem kiedyś nadzieję, że można to wykorzystać do wskazania trwałej lokalizacji zakładek w przypadku, gdy aktualnie wyświetlany URL był niestabilny, na przykład domain.com/ aktualności/najnowsze, ale tak się nie dzieje).
Moja obecna opinia to zapomnij o Content-Location dla HTTP, ale możesz używać go do wysyłania wiadomości MIME.
Rzeczywiście, RFC HTTP twierdzi, że nie ma zdefiniowanego zachowania Content-Location dla PUT i POST. – ordnungswidrig
Zobacz httpbis: część 2, sekcja 6.1: http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-12.html#rfc.section.6.1 –
Jak to się różni od "ja" "relacja łącza? – HDave