WebDAV Method Kullanımı

                                                                                     

    WebDAV (RFC 4918) kaynakların dağıtılmış olarak yazılması ve versiyonlaması için HTTP'nin bir uzantısıdır. Bu uzantı HTTP yi genişletir ve dosya , belgeleri yönetmek için bir dizi HTTP yönetimi ve başlığını belirtir. Bu protokol aşağıdaki uzantın yöntemlerini içerir. 

PROPFIND : 

WebDAV belgelerin özellikleri olabilir ve istemciler bu özellikleri anlamak için bu yöntemi kullanır.

PROPATCH:

İstemciler, kaynakların özelliklerini ayarlamak, eklemek, kaldırmak için bu yöntemi kullanır.

MKCOL

WeDAV belgeleri koleksiyonlar halinde gruplandırmanıza olanak tanır, müşteri bu yöntem ile yeni bir koleksiyon oluşturmak için kullanabilir.

KOPYALA

İstemciler, bir hedef URL belirliği bir kaynağın bir kopyasını oluşturmak için bu yöntemi kullanabilir.

MOVE:

Bu kopyaya benzer ancak sunucunun bu işlemin bir parçası olarak kaynak, kaynağın silinmesi beklenir.

LOCK:

Bu yöntem istemcilerin belirli belgeyi kilitlemesini sağlar. Bu yöntem kötümser eşzamanlılık kontrolünü sağlar.

UNLOCK:

İstemciler önceden kilitlenmiş bir kaynağın kilidini açmak için bu yöntemi kullanabilir.

WebDAV yönteminin "dosya merkezli" işlemler olduğuna dikkat etmek gereklidir.  Kaynakların kolayca kopyalanabilen, üzerine yazılabilen, yeniden adlandırılabilen v.b dosya nesneleri olduğunu varsayarlar.  Ancak çoğu RESTfull web hizmetlerinde kaynaklar dosya değildir ve böyle bir dosya merkezli görünüm genellikle uygulama kaynaklarıyla kolayca eşleşemez.

WebDAV  genellikle belirli bir uygulama etki alanlarının ihtiyaçlarını karşılamak için HTTP nin nasıl genişletileceğinin bir örneği olarak gösterilir. WebDAV uzantıları istemcilerin uzak sunuculardaki belgeleri veya dosyaları düzenlemesine, yönetmesine izin verecek şekilde tasarlanmıştır. Bir kaynağı kopyalamak için örnek;

# Request to copy a resource
COPY /report/working/2010.pdf HTTP/1.1
Host: www.example.org
Destination: http://www.example.org/projections/2010.pdf

# Response
HTTP/1.1 201 Created

İstekte, istemci bir hedef başlığı aracılığıyla kopyanın hedefini seçer. İstemci bu yöntemi özellikler veya koleksiyonlar gibi diğer WebDAV kaynaklarına uygulayabilir. İstemci ayrıca sunucunun bir overwrite üstbilgisi sağlayarak hedef URL de var olan herhangi bir kaynağı geçersiz kılması gerekip gerekmediğini veya bir koleksiyonu kopyalarken derinliği belirtmek için bir Derinlik üstbilgisi belirtebilir.

# Request to copy a resource
COPY /report/working/2010.pdf HTTP/1.1
Host: www.example.org
Destination: http://www.example.org/projections/2010.pdf

Overwrite: F

# Response
HTTP/1.1 201 Created

Benzer şekilde bir kaynağı bir konumdan başka bir konuma taşımak için MOVE yöntemini kullanabilirsiniz.

# Request
MOVE /report/working/2010.pdf HTTP/1.1
Host: www.example.org
Destination: http://www.example.org/projections/2010.pdf

# Response
HTTP/1.1 201 Created
Location: http://www.example.org/archives/this-resource

Hem COPY hemde MOVE yöntemleri atomiktir ve sunucular arasındaki kaynaklara bile uygulanabilir. Örneğin; fiili taşıma işlemi kaynak sunuculardan bir veya daha fazla kaynağın hedef sunucuya yerleştirilemesi ve ardından kaynak sunuculardaki kaynakların kaldırılması gerektirebilir. Sunucu kaynağı yalnızca hedef sunucuda başarılı çoğalttığında kaldırabilir.  Bu yöntemler ayrıca istemcilerin sunucular arasında kaynakları  kilitleme, kilidini açma ve hatta kopyalama gibi ayrıntılarla ilgilenmesini gerektirir.

POST isteklerini Koşullu Yapma

PUT veya DELETE den farklı olarak yapılan bir kaynağa gönderilen POST isteğinin sonucu, herhangi bir istek URI deki kaynağa yapılan değişiklikler sunucuda yeni bir kaynak oluşturabilir. Yanıt kodu 201 veya sonucu farklı bir URI ile tanımlanayabilirsiniz. Yanıt kodu 303. Bu durumda müşterinin bir temsili olmayacak ve şartlı yerel olarak depolanan üstbilgiler dahil. Bu tür POST isteklerini yapmak için bağlantıların nasıl kullanılacağını gösterir. POST  istekleri koşullu veya yanıtsız hale getirmek için bu tarifi uygulayabiliriz. 

Müşteri tarafından sunulması için POST u sunucunun yinelemeleri algılayabileceği ve önleyebileceği şekilde uygulamak istiyoruz.

İstemcilerin her POST isteği için bir bağlantı aracılığıyla sunucu tarafından sağlanan tek seferlik bir URI oluşturmak için  bir jeton içerir. POST isteğinin yalnızca bir kullanım için geçerli olan sunucu. Kullanılan tüm jetonları bir sunucu işlem günlüğünde saklanır. 

İstemci bir POST isteği gönderdiğinde jetonun işlemde mevcut olup olmadığını doğrulayın. Varsa yanıt kodu 403 döndürün. Neden bodyde olduğunu açıklayın. Eğer mevcut değilse dönme isteğine 201 oluşturun yada 303 ile bağlı olarak işlemi sonuçlandırın. Ayrıca belirteci işlem günlüğünde saklayın.

Sunucunun belirli bir miktar transfer etmesi gereken banka havalesi uygulaması olduğunu düşünelim.  Bir hesaptan diğer bir hesaba para aktarımı. Sunucu bir denetleyici kaynağı kullanarak bu transferi uygulayın.

# Request

POST /transfers> İki banka hesabının kaynağına müşteri mevcut durum olduğunu düşündüğü şeye dayanarak bir POST isteği gönderir. 

Host: example.org

Content-Type: application/xml;charset=UTF-8

<transfer>

   <source>urn:example:org:account:1</source>

<target>urn:example:org:account:2</target>

<currency>USD</currency>

   <amount>100.00</amount>

   <note>Testing transfer</note>

</transfer>

# Response

HTTP/1.1 201 Created> Sunucu istemcinin isteğini şuanki duruma dayanıp dayanmadığını hesap kaynalarına göre doğurlayamıyor.

Content-Type: application/xml;charset=UTF-8

Location: http://www.example.org/transactions/1

Content-Location: http://www.example.org/transactions/1

<transfer xmlns:atom="http://www.w3.org/2005/Atom">

   <source>urn:example:org:account:1</source>

   <target>urn:example:org:account:2</target>

   <atom:link href="http://www.example.org/transactions/1" rel="self"/>

   <currency>USD</currency>

   <amount>100.00</amount>

   <note>Testing transfer</note>

</transfer>

Bu örnekte; http://www.example.org/trans tarafından tanımlanan kaynak ters bir denetçi kaynağıdır. Bu örnekteki POST isteğinin sonucu şu şekildedir. iki hesap kaynağının değiştirilmesi ve  yeni bir kaynağın oluşturulaması. Bunu yapmak için istek koşulu olarak; sunucu değerin bir işlev olarak belirteç kullanması gerekir. iki hesap kaynağının mevcut durumu bulabilmek için.  Sunucu aşağıdaki yaratılan URI kullanabilir.

http://www.example.org/transfers;t=e6e3c89d4dfe7f3a818734a6237ccfc5

Değiştirilmesi istenen iki kaynaktan; http://www.example.org/transfers  aksine bu URI bir işlev olarak bir belirteç içerir.  İstemci bir aktarım talebinde bulunmak için URI kullanabilir. Sunucu, URI deki belirtecin hala şuanki duruma karşılıl geldiğini doğrulayabilir. Bir hesap aktarımı oluşturmaya devam etmeden önce hesap kaynaklarını doğrulamak gerekir.

# Request

POST /transfer;t=e6e3c89d4dfe7f3a818734a6237ccfc5 HTTP/1.1 > İstemci geçerli veriyi temel alan bir URI ile koşullu bir POST isteği gönderir. Ancak bu gönderim sadece iki banka hesabı kaynağı olduğu sürece.

Host: example.org

Content-Type: application/xml;charset=UTF-8

<transfer>

   <source>urn:example:org:account:1</source>

   <target>urn:example:org:account:2</target>

   <currency>USD</currency>

   <amount>100.00</amount>

   <note>Testing transfer</note>

</transfer>

# Response

HTTP/1.1 201 Created > Sunucu, istemcinin isteğinin şuanki durumuna dayanıp dayanmadığının kontrolünü yapması ve hesap kaynaklarınında kontrolünün yapması sonrasında.

Content-Type: application/xml;charset=UTF-8

Location: http://www.example.org/transactions/1

Content-Location: http://www.example.org/transactions/1

<transfer xmlns:atom="http://www.w3.org/2005/Atom">

   <source>urn:example:org:account:1</source>

   <target>urn:example:org:account:2</target>

   <atom:link href="http://www.example.org/transactions/1" rel="self"/>

   <currency>USD</currency>

   <amount>100.00</amount>

   <note>Testing transfer</note>

</transfer>

Sunucudaki, jetonun sunucunun işlem günlüğü.

# Request

POST /transfer;t=e6e3c89d4dfe7f3a818734a6237ccfc5 HTTP/1.1 > İstemci koşullu bir POST isteği gönderir.

Host: example.org

Content-Type: application/xml;charset=UTF-8

<transfer>

   <source>urn:example:org:account:1</source>

   <target>urn:example:org:account:2</target>

   <currency>USD</currency>

   <amount>100.00</amount>

   <note>Testing transfer</note>

</transfer>

# Response

HTTP/1.1 403 Forbidden > Sunucu bir çakışma algıdı.

Content-Type: application/xml;charset=UTF-8

Date: Sat, 17 Oct 2019 20:16:18 GMT

<error xmlns:atom="http://www.w3.org/2005/Atom">

   <message xml:lang="en">Transfer already created.</message>

</error>

Bu sefer, sunucu, belirtecin önceden kaydedilmiş olup olmadığını görmek için işlem günlüğünü kontrol eder. Kullanılmış kopya oluşturmak yerine 403 döndürür. Bu teknikte POST tam olarak bir  kez çağrıldı.

Müşterideki Koşullu GET ve HEAD Taleplerinin Yönetimi

Bir müşteri temsilleri yerel olarak deplolandığında koşullu GET veya HEAD isteklerini kullanabilir. Local depoadaki verilerin devamlı olarak güncel olup olmadığını kontrol etmek şartı ile.

Bir sunucu aynı kaynak için GET ve HEAD isteklerinde bulunurken, bu isteklerin "koşullu" yapmak için aşağıdaki maddelerden yaralanır.

* Deplolanan Last-Modified-Since başlığının değerine sahip If-Modified-Since başlığı 

* Deplolanan ETAG başlığı değerine sahip If-None-Match başlığı

Koşullu isteklerin desteklenmesi, Last-Modified ve ETAG başlıklarının depolanmasını ve daha sonra bunları sunucuya gelecek isteklerle birlikte yeniden kullanmak. Aşağıdaki isteğe göz atalım.

# Request

GET /person/joe HTTP/1.1

Host: www.example.org

# Response

HTTP/1.1 200 OK

Date: Sun, 09 Aug 2009 02:55:46 GMT

Last-Modified: Sun, 09 Aug 2009 00:56:14 GMT

Expires: Sun, 09 Aug 2009 03:55:46 GMT

Cache-Control: max-age=3600,must-revalidate

E-Tag: "3f4a74db207d0447d46710a64971e777"

Content-Type: application/xml; charset=UTF-8

<person xmlns="org:example:people" xmlns:atom="http://www.w3.org/2005/Atom">

   <name>John Doe</name>

   <address>

      <street>1 Main Street</street>

      <city>Seattle</city>

      <atom:link rel="self" href="http://www.example.org/person/john/address"/>

      <state>WA</state>

   </address>

   <atom:link rel="self" href="http://www.example.org/person/john"/>

</person>

Bu istek If-Modified içermediği için koşullu bir istek değildir. If-None-Match den itibaren.

Bu temsili müşterinin ileride kullanması için saklanıyorsa, aşağıdakilerin eklenmesi olasıdır.

Kişinin adı, adresi ve depodaki kaynağın URl ayrıca Last-Modified ve/veya ETAG değerlerini her bir temsilci için aynı deploya dahil edilmesi koşullu isteklerde bulunabilmemiz için kullanılması olasıdır.

Daha sonra sunucunun gösterimi aşağıdaki şekilde değiştirilip  değiştirilmediğini kontrol edebilirsiniz. İstekle birlikte If-Modified-Since ve/veya If-None-Match üstbilgiler ile birlikte.

# Request

GET /person/joe HTTP/1.1

If-Modified-Since: Sun, 09 Aug 2009 00:56:14 GMT

If-None-Match: "3f4a74db207d0447d46710a64971e777"

# Response

HTTP/1.1 304 Not Modified

Date: Sun, 09 Aug 2009 03:10:03 GMT

Last-Modified: Sun, 09 Aug 2009 00:56:14 GMT

Expires: Sun, 09 Aug 2009 04:10:03 GMT

Cache-Control: max-age=3600,must-revalidate

E-Tag: "3f4a74db207d0447d46710a64971e777"

Sunucudan gelen yanıt, müşterinin temsilinin kopyasının hala güncelliğini koruduğu. Bu yanıt aynı zamanda güncellik ömrünü bir saat daha uzatır. Bu şekilde sunucu yanıt döner.

Temsilcinin bir kopyasına sahip değilseniz şartlı talepler göndermeyin.

RestFull Web Service Sunucular Arasında İşlemler Nasıl Desteklenir

Sunucu sınırlarını aşan işlemlerin nasıl destekleneceği hakkında kısa bilgi paylaşımıdır. Örneklerde; bir kullanıcı profilini bir uygulamadan diğerine taşımayı özetleri içe aktarmayı içerir. Bir müşteri ilişkileri yönetimi uygulamasında beklenen tekliflerin, taslak sunucudan üretim sunucusundaki belgeler gönderimi. Bu kullanım durumunda birden çok sunucu durumunun değişmesine ihtiyaç doğuyor. İki veya daha fazla sunucu üzerinde içerik işlemlerinin nasıl değişeceğine küçük örnek ile bakacağız.

Sunucular arası operasyonun tasarlamak ve uygulamak için sunucuların birbirleriyle işbirliği yapmasına öncelikle izin verilmeli. (cross-server operations) Bunlar veri formatlar, arka uç ara yüzleri mutabakat sağlayan sunucuları içerebilir. Veri deposundan veri yükleme, onu karşılamak için normalleştirme işlemleri, diğer sunucu biçimleri ve ardından saklanması adımları.

Sunucu sınırlarını aşan işlemlerle karşılaşıldığında endişelerin ayrılması gerekir. 

Kişi listesini dışa aktarmak için bir bağlantıyla birlikte bir kullanıcının kişi listesini temsili mesajlaşma web hizmeti:

# Request

GET /user/smith/contacts HTTP/1.1

Host: contacts.example1.org

# Response

HTTP/1.1 200 OK

Content-Type: application/xml;charset=UTF-8

<contacts xmlns:atom="http://www.w3.org/2005/Atom">

   <atom:link rel="self" href="http://contacts.example2.org/user/smith/contacts"/>

   <atom:link rel="http://contacts.example1.org/rels/export-to-messaging"

      href="http://messaging.example2.org/user/smith/import;

               t=bcb9169866c69410be37f68210a6986c"

      title="Export contacts into to messaging."/>

   <contact>

      ...

   </contact>

   ...

</contact>

     title="Export contacts into to messaging."/> > Bir sunucudan diğerine veri aktarmak için bir URl ile bağlantı kurun.

http://contacts.example2.org/rels/export-to-messaging > anlamı: con ilişki türü ile anlayan bir istemci http://tacts.example2.org/rels/export-to-messaging > dışa aktarma işlemini başlatabilir. Bu bağlantı ilişkisi türünü dökümantasyonunu müşterinin yapması gerektiğini söylediğini varsayalım. 

Kişileri mesaj hizmetine aktarmak için bağlantının URl bir POST isteği gönderin.  Bağlantının  URl yetkisiz kullanımı önlemek için bir güvenlik anahtarı içerir.

# Request

POST /user/smith/import;t=bcb9169866c69410be37f68210a6986c HTTP/1.1

Host: messaging.example2.org

# Response

HTTP/1.1 303 See Other

Location: http://messaging.example2.org/user/smith

Content-Type: application/xml;charset=UTF-8

POST /user/smith/import;t=bcb9169866c69410be37f68210a6986c HTTP/1.1 > Veriyi dışarıya aktarma talebi

Location: http://messaging.example2.org/user/smith > Dışarıya aktarma sonuçlarını sağlayan URl.

 İstemci bu isteği gönderdiğinde mesajlaşma hizmeti bir arka uç isteğinde bulunur. Bu istek Rehber hizmetinin bir kopyasını alabilmek için Rehber web hizmetine bağlanır. Bu işlemler sırasında sunucular arasında güvenliğin nasıl yönetildiğine dair mesajlaşma web servisi mevcut olabilir. Kişiler web hizmetinin URl dahil edilen bir belirteç yardımıyla.

Bu süreçte sunucular kişi listesi verilerinin yapıldığından emin olmaktan sorumludur. Müşteri yalnızca operasyonu tetiklemekten sorumludur. Bu istemciyi sunucunun uygulama ayrıntılarından ayrı tutar. Eşzamanlı kontrol, Eşzamanlı , veri formatlarındaki farklılıklar v.b Sunucu arasındaki koordinasyonun sonuçlarındandır.

Teknik veya organizasyon nedeniyle böyle bir koordinasyon mümkün olmadığında veya bölgesel sorunlardan dolayı,  istemcinin tüm kişileri indirmekten başka seçeneği yoktur. 

URL lerdeki Hasas Bilgiler

 

  URL üzerindeki verilerin kurcalandığını algılamak için algoritmaları kullanarak URL üzerindeki verilerin dijital imzasını hesaplayabiliriz. HMAC-SHA1 ve RSA-SHA1 gibi. URL kaynağına imzayı bir sorgu parametresi gibi eklemek.

URL lerdeki veriler gizliyse AES, Blowfish veri algoritmalarını şifreleyin. DES, Triple DES, Serpent, Twofish v.b URL dahil olan sonucu Base64 olarak kodladığınızdan emin olun.

Örnekte; Sigorta teklif örneğinde; sunucu gösterimindeki bir bağlantıda bir alıntı yayınlamak için kullanılan verileri kodlar.  Teklife göre sigorta satın almak için bağlantıyı kullanır.

# Request

GET /quotegen?fname=...&lname=...&... HTTP/1.1

Host: www.example.org

# Response

HTTP/1.1 200 OK

Content-Type: application/xml;charset=UTF-8

<quote xmlns:atom="http://www.w3.org/2005/Atom">

   <driver>

      ...

   </driver>

   <vehicle>

      ...

   </vehicle>

   <offer>

      ...

      <valid-until>2009-08-02</valid-until>

      <atom:link href="http://www.example.org/quotes/buy?fname=...&lname=...&..."

               rel="http://www.example.org/quotes/buy"/>

   </offer>

</quote>

Bağlantıda kullanılan URL deki kodlanan durum kurcalamaya eğimlidir. Bunu önlemek için sunucu teklif oluşturmak için kullanılan tüm önemli parametrelerin imzasını içerebilir.

http://www.example.org/quotes/buy?fname=...&lname=...&...&sign=f5b244520c2a452a0ee8c8b6ab5b6828317d2f7f

Bu örnekteki imza HMAC-SHA1 ve bilinen bir imza kullanılarak hesaplanmıştır. İstemci bir talep de bulunduğunda sunucu imzayı yeniden hesaplar, URL dahil edilen verilerin bir kısmı ve URL de bulunan imza ile karşılaştırın. Bu değer arasındaki herhangi bir fark verilerin tahrif edildiğini gösterir.

Sunucu bunun yerine durumu şifreleyebilir ve şifreli durumu kullanabilir.

http://www.example.org/quotes/buy?gZwEW9oJIlZhYa1CuJ9IshGyvYJp2Gfo99M5115

hWRKk497mkAOrnBZhkSb18UBzYftLpnryxUT2Y0C8GFDpNT64hypV4kMu

TLS kullanmak bir seçenek olmadığında; sunucu istemcinin gövdeyi eklemesini isteyebilir. İmzadaki talebin durumunda, sunucunun bir tanımlayıcı ataması ve her müşteri için paylaşılan bir  imza ve müşterinin kullanması gereken algoritmayı belgelendiren imzalar oluşturur. Örnek; OAuth istekleri için şunlar içerir.

* Talebin gövdesinde yer alan herhangi bir parametrenin imzası;

* Özet kimlik doğrulaması qop=auth-int ile birlikte; isteğin gövdesini de özetin bir parçası olarak kullanır.

Her iki yaklaşımda talebin bütünlüğünü sağlar.

İstemcilerin Kimlik Doğrulamasında Temel Kimlik Doğrulama Kullanımı

 

  İstemcide, müşteri tanımlayıcısının birleştirilmesi kullanıcı adı ve paylaşılan şifre <identifier>:<secret> ardından bu metinin Base64 kodlamasını dahil etmeniz gerekir. İstemci isteklerinde bir metin başlığı ortaya çıkaran metin değeri : Authorization: Basic <Base64 encoded value>

Sunucuda metnin kodunu çözün ve şifrenin aynı olduğunu doğrulayın. İstemci sunucunun bir kaynak için temel kimlik doğrulaması gerektiğini önceden biliyorsa her istek geldiğinde yetkilendirme üst bilgisi içerilebilir. 401 alınması önlenebilir.

iki kişi için temel ve özet kimlik doğrulama gibi kimlik doğrulama şemaları kullanılabilir.

Senaryolar: Bir müşteri korunan bir kaynağa kendi adına eriştiğinde ve bir müşteri bir kullanıcı adına korumalı bir kaynağa erişiyorsa.

İstemcide güvenli bir şekilde saklanmadıkça hiç bir sır gerçekte güvenli değildir.

Temel kimlik doğrulama; HTTP 1.0'a kadar uzanır ve daha sonra RFC 2617 tarafından belirtilir. Temel kimlik doğrulamasında istemci Base 64 paylaşılan şifre kodlar ve bunu Yetkilendirme isteği başlığı ile destekler.

Base64 kodlaması tersine çevrilebilir. Aşağıdaki durumlarda temel kimlik doğrulaması kullanmayın. Sunucuya bağlanmak için TLS kullanmaz.

Aşağıdaki kodda bir kaynağa erişmeye çalışan bir istemcinin ilk isteğine yer verilmiş.

# Request

GET /photos HTTP/1.1

Host: www.example.org

# Response

401 Unauthorized

WWW-Authenticate: Basic realm="Photos App"

Content-Type: application/xml;charset=UTF-8

<error xmlns:atom="http://www.w3.org/2005/Atom">

   <message>Unauthorized.</message>

</error>

# Request

GET /photos HTTP/1.1 > Kimlik bilgileri olmayan bir istek

# Response

401 Unauthorized

WWW-Authenticate: Basic realm="Photos App" > Temel kimlik doğrulaması kullanarak kimlik bilgilerini sağlamayı zorlayan yanıt.

Kaynak korunduğundan, sunucu istemcinin kimlik bilgilerini sağlamasını ister. Basic adlı bir kimlik doğrulama şeması kullanarak, gerçek değeri opak dizedir. Sunucuda korunan bir alanı tanımlar.

İstemcinin / kullanıcının paylaşılan gizli değeri ile photoapp.001 olarak tanımlandığını varsaydığımızda basicauth. istemci photoapp.001. dizesinin Base64 kodlamasını hesaplar.  Cauth ve Yetkilendirme başlığıyla aşağıdaki isteği gönderir.

# Request

GET /photos HTTP/1.1

Host: www.example.org

Authorization: Basic cGhvdG9hcHAuMDAxOmJhc2ljYXV0aA==

# Response

HTTP/1.1 200 OK

Content-Type: application/xml;charset-UTF8

Authorization: Basic cGhvdG9hcHAuMDAxOmJhc2ljYXV0aA== > Sunucu kimlik bilgilerini Base64 kullanarak çözer yöneticinin, istemcinin kattığı sunucu tarafından bilinenle eşleşir ve istemciye izin verilir. Sunucu alınan istekte bir istek daha alırsa yada yetkilendirme başlığı yoksa veya sağlanan yetkilendirme başlığındaki bilgiler ile eşleşmiyorsa sunucu WWW-Authentication hatasını döndürür.

Kimliği doğrulanmış yanıtlar hassas bilgiler içerdiğinden Cache-Control ve Expires üst bilgileri yanıtı için uygundur.

Örneğin; Yanıt istemciye özeldir, paylaşmayı önlemek için Cache-Control :private kullanın. Yanıtı saklamaktan veya diğer istemcilere sunmakta için gelen önbelleklerde kullanılır.

# Request

GET /users/admin HTTP/1.1

Host: www.example.org

Authorization: Basic cGhvdG9hcHAuMDAxOmJhc2ljYXV0aA==

# Response

HTTP/1.1 200 OK

Cache-Control: max-age:3600,private

Vary: Authorization

Content-Type: application/xml;charset-UTF8

Yetkilendirme Başlığını Genişletme

Özet Kimlik Doğrulaması ve OAuth kimlik bilgilerini sunucuya göndermek için bu başlık kullanılır. Örneği Amazonun Basit Deploma Hizmeti (s3)bu başlığı kullanarak istemciler aşağıdaki istek başlığı kullanarak sunucuya kimlik doğrulaması yapar.

Authorization: AWS AWSAccessKeyId:Signature

Burada AWS Amazon tarafından kullanılan kimlik doğrulama şeması için tanımlayıcıdır.  Amazon aynı verilerin imzasını hesaplayarak istemcinin kimliğini doğrular.

İstemcilerin Kimlik Doğrulamasında Özet Kimlik Doğrulama

 Temel kimlik doğrulamaya benzer istemcinin kimlik bilgilerinin özetini sunucuya göndermesi dışında yeniden kimlik gönderim saldırılarını önlemek için mekanizmaları sağlar.

İstemci erişim için bir Yetkilendirme başlığı eklemeden bir istek gönderdiğinde korumalı kaynak dönüş kodu olarak 401 ile birlikte özet kimlik doğrulama şemasında bilgiler alır. Bu bilgiler bir kez yada sınırlı sayıda alınabilen bilgilerdir.

Sağlanan özetin içerisinde depolanan kimlik bilgilerinin bir özetiyle eşleştiğini doğruladıktan sonra Authentication-Info başlığı ekleyin. Bu bilgi sunucu tarafında eşdeğerdir.

İstemciler genel olarak özeti hesaplamak için MD5 kullanır. Temel kimlik doğrulamasından farklı olarak bu teknik şifrelenmemiş bir paylaşılan sırrı değiş tokuş etmez.

# Request

GET /photos HTTP/1.1

Host: www.example.org

# Response

401 Unauthorized

WWW-Authenticate: Digest realm="Sample app", nonce="6cf093043215da528d7b5039ed4694d3",

         qop="auth"

Content-Type: application/xml;charset=UTF-8

<error xmlns:atom="http://www.w3.org/2005/Atom">

   <message>Unauthorized.</message>

</error>

# Request

GET /photos HTTP/1.1

Host: www.example.org

Authorization: Digest username="photoapp.001", realm="Sample app",

nonce="6cf093043215da528d7b5039ed4694d3",

         uri="/photos", response="89fba5bf5e5f9dd69865258c21860956",

         cnonce="c019e396409afe784ae9f203b8dfdf7e", nc=00000001, qop="auth"

# Response

HTTP/1.1 200 OK

Content-Type: application/xml;charset-UTF8

GET /photos HTTP/1.1   > kimlik bilgisi olmayan bir istek;

# Response

401 Unauthorized

WWW-Authenticate: Digest realm="Sample app", nonce="6cf093043215da528d7b5039ed4694d3",

qop="auth" > nonce içeren yanıt

cnonce="c019e396409afe784ae9f203b8dfdf7e", nc=00000001, qop="auth"  > Yanıt yönergesi içeren istek.

Temel kimlik doğrulamasından farklı olarak özet kimlik doğrulaması, istemcinin bir özet sağlaması gerekir.

realm : Sunucudaki korumalı alanı tanımlayan opak bir dize.

nonce: Her 401 Yetkisiz yanıtıyla benzersiz şekilde oluşturulan dize. Bir özet oluştururken bu değeri kullanmaları gerekir. Yeniden isteklerde kullanılan bazı değerlerden daha eski nonce yönergeleri kullanarak yapılan saldırıları içerir.

qop: Özet kimlik doğrulaması yönergeler için iki değer belirtir. Aut ve Auth-int. 

Auth:  Sunucunun istemci kimlik doğrulaması için özet kimlik doğrulaması kullandığını belirtir.

Auth-int: Sunucunun bu kimlik doğrulamasını aynı zamanda isteklerin bütünlüğü Qop = auth-int istemcilerin isteğinin gövdesine özeti hesaplarken ekler. 

*İstemci / Kullanıcı tanımlayıcısının, alanı ve paylaşılan gizli değer aşağıdaki şekilde birleştirin.  MD5 değerini hesaplayın. Değeri : A1 dir.

<identifier>:<realm>:<secret>

*İstek Yönetimini ve istek URL sini <method>:<URI> MD5 ekleyin. Sonucunun A2 olduğunu söyleyin.

*A1, nonce ve A2 yi <A1>:<nonce>:<A2> olarak birleştirin ve MD5 değerini hesaplayın.

Kullanıcı elde edilen değeri yanıt değeri olarak kullanır.

Nonce kullanımında; Sunucular tek seferlik veya sınırlı kullanımlı bir belirteç kullanarak saldırıların yeniden tekrarlanma olasılığını sınırlayabilir.

Tek seferlik veya sınırlı kullanılan biletler, requestlerde sunucunun kullanılan tüm belirteçlerinin günlüğünün tutulması gerekir.

WWW-Autheticate başlığı ayrıca domanin, opaque gibi diğer direktifleri içerebilir.