Özel HTTP üstbilgileri: adlandırma kuralları

Kullanıcılarımızdan bazıları, bize gönderdiğimiz isteklerin HTTP başlıklarına , hatta API'mizden aldıkları yanıtlara hesaplarına ilişkin verileri eklememizi istedi . Adlandırma , biçim ... vb . Bakımından özel HTTP üstbilgileri eklemenin genel kuralı nedir?

Ayrıca, web'de tökezlediğin herhangi bir akıllı kullanımını yayınlamaktan çekinmeyin; Bunu hedef olarak en iyi olanı kullanarak uygulamaya çalışıyoruz :)

Öneri edilir oldu "X-" ile isimlerini başlatın. Örneğin X-Forwarded-For, X-Requested-With. Bu, RFC 2047'nin 5. bölümünde de belirtilmiştir .

Güncelleme 1 : Haziran 2011, ilk IETF taslağı gönderildiğine kullanımdan kaldırmak standart dışı başlıklar için "X-" öneki kullanılarak tavsiyesini. Bunun nedeni, "X-" ön ekine sahip standart dışı başlıklar standart hale geldiğinde, "X-" önekinin kaldırılması geriye dönük uyumluluğu bozar ve uygulama protokollerini her iki adı da desteklemeye zorlar (Örn. x-gzip& gzipŞimdi eşdeğerdir). Yani, resmi öneri onları "X-" öneki olmadan mantıklı bir şekilde adlandırmaktır .

Güncelleme 2 : Haziran 2012'de, "X-" önekini kullanma önerisinin kullanımdan kaldırılması RFC 6648 olarak resmileşti . Aşağıda alaka düzeyi belirtilmiştir:

3. Yeni Parametrelerin Yaratıcıları için Öneriler

...

3. Parametre adlarını "X-" veya benzeri yapılarla önek ETMEMELİDİR.

4. Protokol Tasarımcıları için Öneriler

...

4. "X-" öneki veya benzeri yapılara sahip parametrelerin kaydedilmesini yasaklamamalısınız.

5. "X-" önekine veya benzeri yapılara sahip bir parametrenin standartlaştırılmamış olarak anlaşılması GEREKMEMELİDİR.

6. "X-" öneki veya benzeri yapıları olmayan bir parametrenin standartlaştırılmış olarak anlaşılması GEREKMEMELİDİR.

"NOT NOT" ("cesareti kırılmış") "MUST NOT" ("yasak") ile aynı değildir, bu anahtar kelimelerle ilgili başka bir spesifikasyon için ayrıca RFC 2119'a bakın . Başka bir deyişle, "X-" ön ekli başlıkları kullanmaya devam edebilirsiniz, ancak artık resmi olarak önerilmemektedir ve bunları herkese açık standartmış gibi belgeleyemezsiniz.

Özet :

• resmi öneri onları "X-" öneki olmadan mantıklı bir şekilde adlandırmaktır
• "X-" ön ekli başlıkları kullanmaya devam edebilirsiniz, ancak artık resmen önerilmemektedir ve bunları herkese açık standartmış gibi belgeleyemezsiniz.

Soru yeniden okuma ile ilgilidir. Sorulan asıl soru, gelecekteki kanıtlama ve satıcı desteği ve resmi standartlar hakkında düşünmenin uygun olduğu CSS mülklerindeki satıcı öneklerine benzemez. Sorulan asıl soru, URL sorgusu parametre adlarını seçmeye daha benzerdir. Kimse ne olduklarına aldırmamalı. Ancak, özel olanları adlandırmak, yapılacak çok geçerli ve yaygın ve doğru bir şeydir.

Gerekçe:
Yaklaşık olduğu özel, uygulamaya özgü başlıklar için geliştiriciler arasında sözleşmeler - " kendi hesabına ilgili verilere geliştirici dışında üçüncü şahıslar tarafından hayata geçirilmesini satıcıları ile ilgisi var, standart kuruluşları veya protokollere -" söz konusu olan sadece sunucular, proxy'ler veya istemciler tarafından amaçlanan başka kullanımları olabilecek başlık adlarından kaçınmaktır. Bu nedenle "X-Gzip / Gzip" ve "X-Forwarded-For / Forwarded-For" örnekleri tartışmalıdır. Sorulan soru, URL sorgusu parametre adlandırma kurallarına benzer şekilde, özel bir API bağlamındaki kurallarla ilgilidir. Bu bir tercih ve isim aralığı meselesi; "X" olmadan herhangi bir proxy veya satıcı tarafından "X-ClientDataFoo" tarafından desteklenen endişeler

"X-" öneki hakkında özel veya büyülü bir şey yoktur, ancak özel bir başlık olduğunu açıkça belirtmeye yardımcı olur. Aslında, RFC-6648 ve arkadaşları, "X-" önekinin kullanımının desteklenmesine yardımcı olur, çünkü - HTTP istemcileri ve sunucularının tedarikçileri önekten vazgeçtikçe - uygulamaya özgü, özel API'niz, kişisel verileriniz- geçiş mekanizması, az sayıda resmi ayrılmış başlık adı ile ad-alan çarpışmalarına karşı daha iyi yalıtılmış hale geliyor. Bununla birlikte, kişisel tercihim ve tavsiyem bir adım daha ileri gitmek ve örneğin "X-ACME-ClientDataFoo" (widget şirketiniz "ACME" ise) yapmaktır.

IMHO IETF spesifikasyonu OP'nin sorusunu cevaplamak için yetersizdir, çünkü tamamen farklı kullanım durumlarını ayırt edemez: (A) bir yandan "Forwarded-For" gibi küresel olarak uygulanabilir yeni özellikler sunan satıcılar, vs. (B) istemciye ve sunucuya / uygulamasından uygulamaya özgü dizeler geçiren uygulama geliştiricileri. Spesifikasyon sadece kendisini eski olanla (A) ilgilendirir. Buradaki soru, (B) için sözleşmeler olup olmadığıdır. Var. Parametreleri alfabetik olarak birlikte gruplandırmayı ve bunları standart (A) tipiyle ilgili birçok başlıktan ayırmayı içerir. "X-" veya "X-ACME-" önekinin kullanılması (B) için uygun ve meşrudur ve (A) ile çelişmez. (A) için daha fazla tedarikçi "X-" kullanmayı bıraktığında, (B) olanları o kadar net bir şekilde belirginleşecektir.

Örnek:
Google (çeşitli standart kuruluşlarında biraz ağırlık taşıyan) - bugün itibariyle, cevabımdaki bu hafif düzenlemede 20141102 - şu anda Apache modüllerinin sürümünü belirtmek için "X-Mod-Pagespeed" kullanıyor verilen bir yanıtın dönüştürülmesiyle ilgilidir. Gerçekten Google'ın "X-" olmadan "Mod-Pagespeed" kullanmasını ve / veya IETF'den kullanımını kutsamasını istemesini gerçekten öneren var mı?

Özet:
Sunucunuza / sunucunuzdan veri aktarmak için uygulamanızda özel HTTP Üstbilgileri (çerezlere bazen uygun bir alternatif olarak) kullanıyorsanız ve bu üstbilgiler, açıkça, hiçbir zaman "X-" veya "X-FOO-" önekiyle adlandırmak, makul ve yaygın bir kuraldır.

HTTP üstbilgilerinin biçimi HTTP belirtiminde tanımlanır. Belirtimi RFC 2616 olan HTTP 1.1 hakkında konuşacağım . Bölüm 4.2, 'İleti Başlıkları' bölümünde, bir başlığın genel yapısı tanımlanmıştır:

   message-header = field-name ":" [ field-value ]
   field-name     = token
   field-value    = *( field-content | LWS )
   field-content  = <the OCTETs making up the field-value
                    and consisting of either *TEXT or combinations
                    of token, separators, and quoted-string>

Bu tanım, token ve TEXT olmak üzere iki ana sütuna dayanmaktadır. Her ikisi de bölüm 2.2, 'Temel Kurallar' bölümünde tanımlanmıştır. Jeton:

   token          = 1*<any CHAR except CTLs or separators>

Buna karşılık CHAR, CTL ve ayırıcılara dayandırılır:

   CHAR           = <any US-ASCII character (octets 0 - 127)>

   CTL            = <any US-ASCII control character
                    (octets 0 - 31) and DEL (127)>

   separators     = "(" | ")" | "<" | ">" | "@"
                  | "," | ";" | ":" | "\" | <">
                  | "/" | "[" | "]" | "?" | "="
                  | "{" | "}" | SP | HT

METİN:

   TEXT           = <any OCTET except CTLs,
                    but including LWS>

LWS, tanımı çoğaltmayacağım lineer beyaz boşluktur ve OCTET:

   OCTET          = <any 8-bit sequence of data>

Tanıma eşlik eden bir not var:

The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than ISO-
8859-1 [22] only when encoded according to the rules of RFC 2047
[14].

Yani, iki sonuç. İlk olarak, başlık adının ASCII karakterlerinin bir alt kümesinden oluşması gerektiği açıktır - alfasayısallar, bazı noktalama işaretleri, başka bir şey değil. İkinci olarak, üstbilgi değeri tanımında ASCII ile sınırlayan veya 8 bitlik karakterleri hariç tutan hiçbir şey yoktur : açıkça sekizli karakterlerden oluşur, yalnızca kontrol karakterleri engellenir (CR ve LF'nin kontrol olarak kabul edildiğine dikkat edin). Ayrıca, TEXT üretimi hakkındaki yorum, sekizlilerin ISO-8859-1'de olduğu şeklinde yorumlanması ve bu kodlamanın dışındaki karakterleri temsil etmek için bir kodlama mekanizması (bu arada, korkunç) olduğunu ima eder.

Bu nedenle, özellikle @ BalusC'ye yanıt vermek için, spesifikasyona göre başlık değerlerinin ISO-8859-1'de olduğu oldukça açıktır. Tomcat dışında bir başlıkta yüksek 8859-1 karakter (özellikle Fransızcada kullanılan bazı aksanlı ünlüler) gönderdim ve Firefox tarafından doğru bir şekilde yorumlandım, bu yüzden bir dereceye kadar, bu hem pratikte hem de teoride çalışıyor (bu bir URL içeren bir Konum başlığı olmasına rağmen ve bu karakterler URL'lerde yasal değildir, bu yüzden bu aslında yasadışıdır, ancak farklı bir kural altındadır!).

Bununla birlikte, tüm sunucular, proxy'ler ve istemciler arasında çalışan ISO-8859-1'e güvenmeyeceğim, bu yüzden savunma programlama konusunda ASCII'ye bağlı kalacağım.

RFC6648 , özel başlığınızın "standartlaştırılmış, herkese açık, yaygın olarak konuşlandırılmış veya birden fazla uygulamada kullanılabilir" olabileceğini varsaymanızı önerir. Bu nedenle, "X-" veya benzeri yapılarla önek kullanılmasını önermez.

Bununla birlikte, bir istisna söz konusudur: "[başlığınızın] standart hale getirilmesi son derece düşük olduğunda." Bu tür "uygulamaya özel ve özel kullanım" başlıkları için RFC, satıcı öneki gibi bir ad alanının haklı olduğunu söylüyor.

Ek HTTP üstbilgileri eklemek veya daha doğru bir şekilde değiştirmek, başka bir şey yoksa harika bir kod hata ayıklama aracıdır.

Bir URL isteği bir yönlendirme veya resim döndürdüğünde, hata ayıklama kodunun sonuçlarını geçici olarak yazmak için html "sayfa" yoktur - en azından tarayıcıda görünür olana.

Bir yaklaşım, verileri yerel bir günlük dosyasına yazmak ve bu dosyayı daha sonra görüntülemek. Bir diğeri, hata ayıklanan verileri ve değişkenleri yansıtan HTTP üstbilgilerini geçici olarak eklemektir.

Düzenli olarak X-fubar-somevar: veya X-testing-someresult: gibi şeyleri test etmek için fazladan HTTP başlıkları ekliyorum ve izlemesi çok zor olan birçok hata buldum.

Başlık alanı adı kayıt defteri RFC3864'te tanımlanmıştır ve "X-" ile özel bir şey yoktur.

Anlayabildiğim kadarıyla, özel başlıklar için herhangi bir kılavuz yoktur; şüpheniz varsa onlardan kaçının. Veya HTTP Uzantı Çerçevesine ( RFC 2774 ) bir göz atın .

Kullanım durumundan daha fazlasını anlamak ilginç olurdu; bilgi neden ileti gövdesine eklenemiyor?