HTTP'nin gizli özellikleri

HTTP'nin hangi gizli özelliklerinden bahsetmeye değer olduğunu düşünüyorsunuz?

Gizli özellikler derken, zaten standardın bir parçası olan ancak yaygın olarak bilinmeyen veya kullanılmayan özellikleri kastediyorum.

Lütfen cevap başına sadece bir özellik.

O olmalı ben bir çaydanlık olduğum 418 durum kodu parçasıdır Hiper Metin Cezve Denetimi Protokolü (HTTP uzantısıdır). Her seferinde beni güldürür.

2.3.2 418 Ben bir çaydanlığım

Bir çaydanlık ile kahve demlemeye yönelik herhangi bir girişim, "418 Ben bir çaydanlığım" hata koduyla sonuçlanmalıdır. Ortaya çıkan varlık gövdesi kısa ve sağlam OLABİLİR.

Aslında yönlendiren yanlış yazılmış ve yanlış yazılmış tutulmalıdır karar verildi.

Açık cevap: PUT, DELETE, TRACE, OPTIONS, CONNECT yöntemleri

Çoğu insan GET ve POST yöntemlerini bilir çünkü formları oluştururken kullandıkları şey budur. Tarayıcılar ayrıca HEAD'i çok kullanır. Diğer yöntemler çok daha az bilinir; çoğunlukla daha özel uygulamalar tarafından kullanılırlar.

Hiç kimse 402 Ödeme Gerekli gördü mü ?

204 İçerik Yok

204'ün sadece görüntülenecek içeriğiniz yoksa olduğunu sanıyordum, ancak spesifikasyon , kullanıcı aracısının "belge görünümünü değiştirmemesi" gibi ek bir davranış var gibi görünüyor.

NASIL YAPILACAĞINA göre : Apache'yi AJAX için bir HTTP 204 (İçerik Yok) Döndürecek Şekilde Yapılandırma

FWIW, Google aslında benzer bir şey yapıyor. Bir kullanıcı arama sonuçlarındaki bir bağlantıyı her tıkladığında, Google tıklamayı kaydetmek için kendisine ping atar; ping'den gelen yanıt kodu bir HTTP 204'tür.

Ayrıca, 204 İçerik Yok , yapabileceğiniz her ağ trafiğinin son baytından tasarruf etmek istiyorsanız, bunun "web hataları" veya "işaretçiler" için iyi bir teknik olduğunu önermektedir.

Yanıt Kodu410 Gone :

(...) sunucu sahipleri bu kaynağa olan uzak bağlantıların kaldırılmasını istiyor. (...)

Web örümcekleri (en önemlisi Google) 410 döndürmeye başlayan bir sayfanın indeksini kaldırır (tipik olarak bir sonraki taramada).

Dinamik içerikte Last_Modified veya ETag başlığını kullanın

Bazen büyük ve / veya oluşturulması maliyetli olabilecek ve istekten diğerine değişmeyen dinamik içeriğiniz vardır. Oluşturulan yanıtınıza bir Last_Modified veya ETag başlığı ekleyebilirsiniz.

Pahalı dinamik kodunuzun en üstünde, içerik istekte bulunanın halihazırda sahip olup olmadığını belirlemek için If_Modified_Since veya If_None_Match kullanabilirsiniz. Yanıt durumunu "304 Değiştirilmemiş" olarak değiştirin ve isteği sonlandırın.

Bazı sunucu tarafı teknolojiler bu tür özellikleri resmi olarak sağlar, ancak yukarıdakileri düşük ASP-Classic'te bile yapabilirsiniz.

Bunun Cache-Control, Expires başlıklarını ayarlamaktan farklı olduğunu, istemcinin her zaman talep üzerine en son bilgileri almasını sağladığını unutmayın.

Sen isteyebilir devam kullanılarak (büyük) HTTP yanıt (örneğin dosya indirme) Rangeve If-Rangesırasıyla belirtilen bayt aralığı ve benzersiz dosya tanımlayıcı veya dosya modifikasyonu zaman damgası ile istek başlıkları. Bu, sunucu, sırasıyla sunucunun bayt aralığı isteklerini, benzersiz dosya tanımlayıcısını ve dosya değiştirme zaman damgasını desteklediğine dair bildirimle birlikte ilk yanıtta Accept-Ranges: bytesve ETagveya Last-Modifiedyanıt başlıklarını göndermişse mümkündür .

İlk yanıt şöyle görünebilir ( ETaggenellikle dosya adı, boyutu ve son değişiklik zaman damgasından oluşur):

Accept-Ranges: bytes
ETag: file.ext_1234_1234567890
Content-Range: bytes 0-1233/1234

İndirme işlemi, örneğin 1KB'de (1024 bayt) durdurulduğunda, istemci aşağıdaki şekilde devam edebilir:

If-Range: file.ext_1234_1234567890
Range: bytes=1024-

Bu yanıtı vücuttaki uygun baytlarla döndürmeli:

Accept-Ranges: bytes
ETag: file.ext_1234_1234567890
Content-Range: bytes 1024-1233/1234

Dinlenme , HTTP'yi bir arayüz protokolü olarak sınırlarına kadar zorlamaya çalışır.

Bu gizli bir özellik değil , ancak iyi tanımlanmış ReST API'lerine bakarak, HTTP'nin nasıl çalışması gerektiği konusunda oldukça iyi bir kavrayış elde edebilir ve HTTP yöntemlerinin, durum kodlarının ve başlıkların basit bir kombinasyonu ile nelerin elde edilebileceğine dair harika örnekler bulabilir. ve sağa sola.

Fragman (Başlığın aksine)

Protokol, kendi özel alanlarınızı tanımlamanıza izin verir. Çerezleri kullanmak istemiyorsanız bunlar başka bilgileri taşımak için kullanılabilir.

HTTP 100 (Devam) Durumu

Bir müşteri, bir istek gövdesi ile bir istek mesajı gönderebilir , kaynak sunucunun isteği kabul etmeye istekli olup olmadığını belirlemek için .

Bazı durumlarda, sunucunun göndermesi durumunda istemcinin gövdeyi göndermesi uygun olmayabilir veya son derece verimsiz olabilir. gövdeye bakmadan mesajı reddederse, .

Sahte istemcilerden ve / veya bant genişliğinden kaynaklanan trafikten kaçınmak için kullanılabilir değerli bir meta .

Ancak, bu özelliğin tam olarak kullanılması için HTTP1.1 İstemci, Sunucular ve Proxy'ler için bazı kriterler vardır. HTTP Bağlantıları hakkında daha fazla bilgi için HTTP / 1.1 RFC 2616'ya bakın.

Durum kodları :

• Ne zaman URI http://www.domain.invalid/index.php?id=44 denir eğer sorgu ( id=44) Ressource dönmek olamazdı, neden bir durum kodu vermemelidir 404?
• URI http://www.domain.invalid/index.php?id=foo çağrıldığında idyalnızca tamsayıları kabul ettiğinde , neden bir durum kodu döndürmüyorsunuz 400?
• Neden, yanlış giriş / şifre girdiğinizde, neredeyse tüm web uygulamaları , durum kodu (tamam, sorun değil, iyi yapıyorsunuz) ile birlikte "Kimlik doğrulama başarısız" gibi bir mesaj 200veriyor 401?

Evet, durum kodları bazı web geliştiricileri için HTTP'nin bir tür gizli işlevi gibi görünüyor ... Ama merak ediyorum bu protokolün tüm "özelliklerinin" en büyüğü onun RFC'si değil mi ?