HTTP GET istekleri için bir içerik türü başlığına ihtiyacım var mı?

Anladığım kadarıyla, içerik türünü ayarlayabileceğiniz iki yer var:

1. İstemci, sunucuya gönderdiği gövde için bir içerik türü belirler (örneğin, posta için)
2. Sunucu, yanıt için bir içerik türü ayarlar.

Bu, tüm alma isteklerim için (istemci tarafı) bir içerik türü ayarlamak zorunda olmamam ya da ayarlamamam gerektiği anlamına mı geliyor? Ve eğer yapabilirsem veya yapmalıyım ne tür bir içerik olurdu?

Ayrıca, istemcinin içerik türünün, istemcinin almak istediği içerik türünü belirlediğini birkaç gönderide okudum. Yani belki benim 1. noktam doğru değil?

Göre RFC 7231 bölüm 3.1.5.5 :

Yük gövdesi içeren bir mesaj üreten bir gönderici , ekteki sunumun amaçlanan ortam türü gönderen tarafından bilinmiyorsa, bu mesajda bir İçerik Tipi başlık alanı oluşturmalıdır . Eğer bir içerik-Tipi başlık alanı mevcut olmadığında, alıcı ya da "uygulama / sekizli-akış" (bir ortam tipini varsayabilir [RFC2046], Bölüm 4.5.1 ) veya türünü belirlemek için verileri inceleyin.

Content-TypeHTTP üstbilgisinin yalnızca PUTve POSTistekleri için ayarlanması gerektiği anlamına gelir .

İstekte içerik (yani bir gövde) olmadığı için alma isteklerinde içerik türü olmamalıdır

GET isteklerinde, istemcinin hangi tür içeriği anladığını söyleyen "Kabul Et" başlıkları bulunabilir. Sunucu daha sonra hangi içerik türünün geri gönderileceğine karar vermek için bunu kullanabilir.

Yine de isteğe bağlıdırlar.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1

Kabul edilen cevap yanlış. Teklif doğrudur, PUT ve POST'un sahip olması gerektiği iddiası yanlıştır. PUT veya POST'un gerçekte ek içeriğe sahip olması gerekmez. GET'in aslında içeriğe sahip olmasına karşı da bir yasak yoktur.

RFC'ler tam olarak ne anlama geldiğini söylerler. Tarafınız (istemci VEYA orijin sunucusu) HTTP üstbilgilerinin ötesinde ek içerik gönderecekse, bir İçerik Türü üstbilgisi belirtmelidir. Ancak, İçerik Türü'nün atlanmasına ve yine de içerik eklenmesine izin verilebileceğini unutmayın (örneğin, bir İçerik Uzunluğu üstbilgisi kullanarak).

Kısa cevap: Büyük olasılıkla, hayır HTTP GET istekleri için içerik türü bir üstbilgiye ihtiyacınız yoktur . Ancak, teknik özelliklerin HTTP GET için içerik türü üstbilgisini de dışladığı görülmemektedir.

Destekleyici materyaller:

1. "İçerik Türü", temsil (yani yük) meta verilerinin bir parçasıdır. Alıntı RFC 7231 bölüm 3.1 :

   3.1. Temsil Meta Verileri

   Temsili üstbilgi alanları, temsille ilgili meta veriler sağlar. Bir mesaj bir yük gövdesi içerdiğinde, temsil başlığı alanları yük gövdesinde bulunan temsil verilerinin nasıl yorumlanacağını açıklar. ...

   Aşağıdaki başlık alanları temsil meta verilerini aktarır:

   +-------------------+-----------------+
   | Header Field Name | Defined in...   |
   +-------------------+-----------------+
   | Content-Type      | Section 3.1.1.5 |
   | ...               | ...             |
   

   RFC 7231 bölüm 3.1.1.5'ten (bu arada, seçilen geçerli cevabın bölüm numarasında bir yazım hatası vardı) alıntılanmıştır :

   "İçerik Tipi" başlık alanı, ilişkili sunumun medya türünü belirtir

2. Bu anlamda, Content-Typebaşlık gerçekten bir HTTP GET isteği (veya bu konu için bir POST veya PUT isteği) ile ilgili değildir. Böyle a içeride yük hakkındadır ne talep ediyorum. Yani, yük olmayacaksa buna gerek yoktur Content-Type. Uygulamada, bazı uygulamalar devam etti ve bu anlaşılabilir varsayımı yaptı. Adam'ın yorumundan alıntı :

   "Spesifikasyon ... bir GET'te Content-Type'a sahip olamayacağınızı söylemese de .Net, HttpClient'e zorlar gibi görünüyor. Bkz. SO q & a ."

3. Ancak, kesinlikle belirtmek gerekirse, özelliklerin kendisi HTTP GET'in bir yük içerme olasılığını dışlamaz. Alıntı RFC 7231 bölüm 4.3.1 :

   4.3.1 ALIN

   ...

   Bir GET istek mesajındaki bir yükün tanımlanmış bir anlamı yoktur; bir GET isteğine bir yük gövdesi göndermek, mevcut bazı uygulamaların isteği reddetmesine neden olabilir.

   Dolayısıyla, HTTP GET'iniz herhangi bir nedenle bir yük içeriyorsa, bir Content-Typebaşlık da makul olabilir.

Bir GET iletisinde içerik türünü geçmeme sorunu, sunucu tarafı içeriği yine de belirlediğinden içerik türünün alakasız olduğundan emin olunmasıdır. Karşılaştığım sorun, artık web hizmetlerini geçtiğiniz içerik türünü alıp yanıtı istediğiniz 'tür' biçiminde döndürecek kadar akıllı olacak şekilde ayarlayan birçok yer olması. Örneğin. şu anda varsayılan olarak JSON olan bir yerle mesaj gönderiyoruz, ancak xs içerik türünden geçerseniz JSON varsayılanları yerine xml döndürecekleri için web hizmetlerini ayarladılar. Sanırım ileriye gitmek harika bir fikir