27 Mart 2022 Pazar

ERWIN ROMMEL - AUFTRAGSTAKTİK, TRUPPENFUHRUNG, Blitzkrieg, Wüstenfuchs

    


  2 Dünya Savaşının akılda kalan komutanlarından ERWIN ROMMEL 1891 Alman İmparatorluğunun topraklarında dünyaya geldi. Orta sınıf elit tabakadaki bir aileden gelen ROMMEL çocukluk hayallerinde zeplin tutkusundan dolayı asker olmaya karar verdi. Piyade sınıfından orduya giren ROMMEL 1911 de Danzig - Kriegsschule gönderildi. Okulda orta seviyede subay başarı gösteren ROMMEL. 1912 alında teğmen olarak göreve başlamasından sonra 1. Dünya Savaşı ortaya çıktı. 124. Piyade görevi yapan ROMMEL batı cephesinde Fransızlara karşı savaştı. Madalyalar kazanarak başarı sağladı. 1915 üst teğmen olduktan sonra dağ taburuna gönderildi. Romanya Cephesinde savaşa gönderildi. Burada ilk kez farklı bir savaş stratejisi ile savaştı 1917 de Almanlar yeni bir  savaş taktiğinde hız, esnekli, yaratıcılık  farklı bir savaş taktiği ile savaşmaya başladılar. STOSSTRUPP denilen bu taktik ile düşman hatları arkasına geçilerek karşı tarafın ikmal hatlarının kesilmesi taktiği idi. Gözü pek tutkulu komutanların yapabileceği bir taktik idi. Romanya'dan sonra ITALYA cephesinde de savaştı ve başarılı oldu ve Yüzbaşılığa yükseldi.

Piyade okuluna eğitmen olarak atandı, 1932 de Binbaşılığa terfi etti. Goslardaki Avcı taburunun komutanlığına getirildi. 1935 de Yarbaylığa yükseldi ve eğitim subaylığına devam etti. 1937 Piyade Taaruzu kitabı yayınladın bu kitap asker anısı olmaktan çıktı ve askeri okullarda okutulan kitap oldu. HİTLER JUGEND örgütünde eğitmen olarak göreve devam etti ve  Albaylığa yükseldi. İlhak edilen Avusturyada askeri okullarda eğitmen olarak atandı. 1939 da Tuğgeneralliğe yükseldi. 1940 da Fransaya savaş açmadan 10 panzer tümeninden 7 nci panzer tümenin komutanlığına getirildi.  

Şimdiye kadar tabur komutanlığı deneyimi yoktu ve zırhlı birlik komutanlığı deneyimide yoktu. Bu eksiklere rağmen göreve getirildi. Düşmanın pes etmesi için üzerine gildilmesini gerektiği düşünülüyordu. 1940 Mayısda harekat başladı. 10 panzer tümeni Fransa üzerine yarma harekatı ile devam edilmesi kararı verildi. Yıldırım hareketi ile düşmanın arkasına geçip ikmal noktalarını kontrol edip düşmanı ablukaya alıp, imha edecekti. Nehiri geçmek için hemen botlara panzerleri yükleyip diğer birlikleri beklemeden hemen taarruza geçti. Fransızları hazırlıksız yakalayıp  düşürmek istemekteydi. Kolordu komutanın emirlerini dinelemiyor. Diğer panzerler ile beraber haraket etmesi gerekirken haraket etmiyor. 5 nci panzer tümenin komutanı ile geçinemiyordu. Kafasına göre haraket edip bildiğini yapıyordu. ROMMEL hızlı hareket ederek nehiri  geçip diğer tümenleri arkada bırakıp hızlıca ilerledi. Almanlar 7 inci tümenin düşman tarafından ele geçirildiğini zannedip telsiz bağlantısınıda kaybettikleri için telaşa düştüler. Tekrar bağlantı kurulduğunda ROMMEL Fransız hattını yarmış. Arrasa geçen ROMMEL ilk İngiliz çatışmasında başarı gösteren Alman hattının yarılmasını önledi. 

Müttefiklerin Dunkrikden kaçamayan birliklerini esir aldı. Taarruz esnasında ortadan kaybolarak hızlı hareket etmesi ile  ünlenen ROMMEL hayalet birlik olarak anılmayan başladı.

Fransız cephesinin 2 nci evresinde büyük başarılar elde ettik. Düşman hattını yaran ilk tümen olan 7 inci tümen batı Fransanın işgalini gerçekleştirdi. 240 KM yolu bir günde kat ederek büyük bir üne kavuştu. Panzer tümen komutanları arasında en aktif ve en atılgan olan ROMMEL. 97.000 asker esir almış, 400 Tank, 4000 Kanyon, 64 Tanksavar 277 Sahra Topu ele geçirdi.  Alman savaş taktiğinin ana felsefesi  Helmut Bernhard von Mottie tarafından söylenmiş,  düşmanın ana unsurları ile temas edildikten sonra hiçbir plan geçerliliğini koruyamaz. Almanların taktik sistemden ziyade bir komuta metodu olan AUFTRAGSTAKTİK benimsemelerine yol açmıştır. 

Bu methoda üst seviye komutanlar hedef en sade ve net şekilde belirler, Sahadaki birlik komutanlarıda mevcut yöntemle nasıl ve ne şekilde yapılacağına karar verirler. Hız,Esneklik, Lojistik,Hareket 4 maddeninden olması gerekli idi. Bu seviyede işletilmesi için Subayların  en iyi şekilde yetiştirilmesi gerekiyordu. Alman subayların Avrupdaki subaylara göre daha eğitimli, maharetli, disiplinli olmaları gerekiyordu. Alman takdiğinde önemli olan şey komuta becerisi idi.

Osmanlı Döneminin Subaylarının çoğunundan AUFTRAGSTAKTİK taktik yöntemi ile yetiştirilmişlerdir.

Savaş sonrası yayımlanan TRUPPENFUHRUNG talimnamesi ile bir ordunun muharebe gücü subay ve asker kalitesi belirlerdi. Muharebe akibetide hareket esnasında manevra, sevk ve idaredeki hızı belirlerdi. 

Savaş enasında vaziyet hızlı ve en iyi şekilde değerlendiren komutan savaşı kazanırdı. ROMMEL in bu doğal becerisi sayesinde diğer komutanlardan bir adım önde çıkıyordu. Yukarıdan dur emri gelmesine rağmen eğer bir fırsat kaçacağını görebiliyorsa emri kimden gelirse gelsin dinlemiyordu.  Savaş sırasında tank üzerinde ve ön saflarda yer alarak savaşın işleyişi hakkında daha net bilgi sahibi olmak için bağlı birlikleri ile telsiz temasında bulunur. Ast Subayların işlerini denetler askerin üzerinden gözünü ayırmazdı. 

Üst Yönetim için başarılı olması gerekiyorsa herşeyi yapabilirdi. 


ÇÖLDE ŞAVAŞ

MUSSOLİNİ  Almanlardan yardım istedi ve ROMMEL TümGeneralliğe terfi ettirilerek birlik başında ITALYA ya gönderildi. Şubat 1941 Trablusgarp gelen komutan 2 Nisan ElAgilayı aldı. İtalyanların ve Almanların daha ileri gitmemesini iletmelerine rağmen kendisi İngilizlerin zayıf olduğunu sezerek İngilizlerin üzerine gitti. Birliklerini 3 e ayrılarak saldırıya geçti.

Bingazi , Derme Mechilli ele geçirilidi. Hedefinide İngilizlerin sömürge yolu olan Süveş kanalı olarak belirledi.  Hızı kesmeden Tobruk kuşatıldı. Ancak Tobruk Almanların başının belası olmuş bir türlü düşürülememişti. ROMMEL devam edebilmesi için takviye almasın ve desteklenmesi gerekiyordu. Çünkü karargahtan çok uzağa gitmişti. Destek alamadı. İngilizler takviye yapıyor ve askeri kuvvetlerini güçlendiriyordu.  Almanya azda olsa destek verebildi ve Afrika Panzer Grubunu kurup ROMMEL i KoreGeneralliğe yükseltti. ingiliz 8. Ordu yeniden tazelenmişti.  İngilizler hazırlandıklarında taarruza geçtiler ROMMEL tutunamayacağını anlayınca adım adım geri çekilmeye başlar. Başladığı yere  geri çekilir. Hava ve Logistik desteğin önemini anlayıp yaptığı hatları ve planlarını yeniden gözden geçirdi. 

En büyük hatası askerlerinden çok büyük isteklerde bulunması ve askerlerini çok zorlamasıydı. ÇÖL TİLKİSİ olarak anılan ROMMEL 21 Ocaksa yeni takviyeleri ile toparlandı ve yeni taarruz başlattı. 4 Şubatta GAZALA ya vardı. ORGENERAL terfi ettirildi. Elindeki birlik adıda Afrika Panzer Ordusu oldu. İngilizler ağır bir yenilgi alarak Tobruku bırakıp Mısırın içerisine doğru çekildiler. ROMMEL adını tüm Dünyaya duyurdu ve Maraşellik ünvanını kazandı. 

El Alamein kadar ilerledi ancak bu ilerleme sonrasında ikmal , istihbarat ve ikmal gücü olarak zayıflamışlar bu durumda kuvvet İngilizlere geçmişti. ROMMEL in amacı düşmanı açık alana çekmek ve düşmanı parçalara bölmek ve küçük lokmalar halinde imha etmekti. 

Çöl ikliminden de dolayı 2 KASIMda geri çekilme emri verildi. Başarılarının biride Tüm ordusunu arkasında İngiliz ordusunun kovalamasına rağmen tüm orduyu Trablus geri çekebilme başarısıdır. 

Yeni yapılandırılan Afrika Ordular Grubunun başına getirildi. Almanyaya geri döndü. 


KARŞI ATAK

    Almanların Doğu Cephesinde istikrara kavuşmasından sonra kaynaklarını Afrikaya yönlendirme kararı ile 7 Aralıksa Pasifikteki Japon tehditlerine karışılık vermek için 21 Ocak 1942 de ROMMEL karşı atak vermek için geri çekilme haberi yayıldı. Ancak  bu geri çekilme haberine İngilizler ihtimal vermiyorlar Londra dan istihbarat istiyorlardı. Ingilizler  tereddüt içerisinde beklemeye başlamışken; 21 Ocak günü General Almanların en iyi bildiği taktik Blitzkrieg taktiği yani yıldırım harekatı. Durdurak bilmeyen ve hareket dayalı bir taktik olan bu taktikte; Ecdebiyye, Bingazi ele geçirilmişti. Gazzala Savunması önünde ROMMEL Afrika Cephesi denince ilk akla gelen ve etrafın kan gölüne döndüğü bu savaşta; 90.000 kişilik Mihver ordu 150.000 aşkın müttefik ordusu bulunyor. Mayıs ayı ortalarında 1 hafta gündüzleri doğu yönünde geceleri ise ters yönde hareket etmektedirler, İngiliz hava birlikleri gündüz keşif repolarında Gazala sahil şeridine büyük miktarda birlik aktarıldığını rapor etmişlerdir. Doğal olarak İngiliz kuvvetleri doğu cephesine yığınak yapılıyor raporu ile ROMMEL taktiği ile  ingilizlere Almanlara sahile yığılıyorlar buradan çıkarmak yapacaklar şeklinde öngörüde bulunmuşlardır.  Cephe gerisinde eski uçak motorlarına yüklenen kamyonlar tozu toprağa katmaktadır. İngiliz hava kuvvetleri cephe gerisinde piyade birliklerine kıyasla motorize ekiplerin takip ettikleri raporunu iletmişlerdir. Bu yanıltmacayı da İngilizler görememişlerdir. 21 Haziran 1942 de Tobruk  düşmüş ve 35.000 Biritanyalıda şehirle beraber esir düşmüştür. Adını dünyaya duyurmuş ve Maraşelliğe yükseltilmiştir. ROMMEL Alman ordusunun propoganda aracı olmuş Alman haklının en sevdiği düşmanlarınında en korktuğu komutan haline gelmiştir. Askerleri arasında bir idol haline gelen ROMMEL yaşayan bir Alman efsanesi olmuştur. Çöldeki bu savaş sonrasında ona bir lakap bulmuşlardır. Çöl farelerini avlayan Çöl tilkisi yani Wüstenfuchs.. Bu denli büyük çaplı ve eşit sayılardaki savaşlar arasındaki başarıyı küçük detaylar belirler bazen motivasyon bazen kumandanların zekasıdır.  

    ROMMEL in bu savaşlardaki başarısının kişisel zekasının yanıdan birde istibahrat işi vardır. İtalyanların Müttefiklerin Afrika kuvvetlerin Amerika ile yazışmaları sırasında konsolosluktaki haberleşme kodunun kırmışlardır. ROMMEL karşı tarafın ne zaman hangi pozisyonu alacağını önceden haber aldığı için birliklerinde ona göre karşı atak ile cevap vermekteydi. Yıldırım saldırısı ile ilerleyen ROMMEL in ekibi , Haziran sonuna kadar El Alamein kadar ilerlemişti. Buranın ardı artık Süveyş kanalı idi. İngilizler için buranın düşmesi savaşın kaybedildiği anlamına geliyordu ve var güçleri ile burayı savunmaları gerekiyordu. Almanların İngiliz  kodlarına sızdığının anlayan Amerikalılar kodlarını değiştirdi. ROMMEL kendisinden 2 kat büyük olan düşmana karşı artık bundan sonra körlemesine savaşmak zorunda kalacaktı. Akaryakıt ve hava saldırıları, yeterli tank kalmaması, askerlerin uzun süre savaşması yüzünden yorgun düşmeleri neticesinde   ROMMEL daha fazla dayanamadı ve çekilme kararı vermek üzereydi.  ROMMEL; ölenler şanslı onlar için herşey bitti. Kalanlar bir şekilde savaşmak zorundaydı. Almanların akaryakıt taşıyan gemilerinin batırıldığını öğrenen ROMMEL karısına yazdığı mektupda düşmanın çokluğu bizi ezdi diyordu. Siper savaşına girdiğinde asker  sayısı İngilizlerde daha çok olduğu için savaşı daha çok askere sahip taraf kazanacağını bildiği için ROMMEL çekilmeye karar verdi. ROMMEL hitlere mektup yazarak artık kazanma şansı yok geri çekilmek için izin istedi. Hitler ise ya ÖL yada ZAFER kazan dedi. ROMMEL emri dinlemedi ve geri çekilme emri verdi, bundan sonra bir başka savaş olacaktı "hayatta kalma savaşı" aştığı çölü tüm askerlerinin hayatlarını kurtarmak için nizami bir şekilde geri çekmeye başladı.  1943 ylında ROMMEL askerlerini  Tunusa ulaştırmayı başardı. Bazı tarihçilere göre Alman Kolordusunun hayatını kurtarmak için binlerce kilometrelik çölü koşarca aşması ROMMEL in en büyük başarısıydı. 

ROMMEL askelerinin Almanyaya göndermek istesede Hitler buna karşı çıkmış sadece kendisinin gelmesini emretmişti. Afrika Cephesinde 130.000 civarı asker esir düştü.


B Ordular Gurubu Komutanı Fransanın batısındaki kısmı savunması için gönderildi. Müttefiklerin olası çıkarma için tedbir alan ROMMEL 2600 KM Atlantik kıyısı boyunca askerleri denetlendi.


Normandiya çıkarmasın sonrasında hasta yatağındayken Hitlere suikast girişiminde olan takım içerisinde adının çıkması sonrasında Hitlerin kendisini öldürmesini emretmesi sonucunda Hitlerin Ailesine bir kötülük yapacağını düşünerek Ailesini korumak için intihar etti. Generalin Suikast  takımında olup olmadığı hala tarihçiler tarafından da tartışmalı bir konudur.


13 Mart 2022 Pazar

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.


27 Şubat 2022 Pazar

RestFull WebService - Kaynak Taşıma

 

   Kaynağı taşıyabilen bir denetleyiciye bir bağlantı şablonu eklenmesi gerekir. Taşıma isteği göndermek için POST kullanılır. İsteği işledikten sonra yanıt kodu 201 veya 303 sonuca bağlı olarak döndürülür.

Bir hareketin anlamı tamamen uygulamaya özgüdür. Kaynağın aynı veya farklı bir sunucuda farklı bir konuma gönderiliyor ve orjinal siliniyorsa,  yeniden kopyalamak anlamına gelebilir.  Alternatif olarak, bir kayanğın durumunu değiştirmeden değiştirmek anlamına da gelebilir. Bir hareketin ne anlama geldiği ve sunucunun bunu nasıl uyguladığı hakkında ve  her iki durumunda da sabit olmayan bağlantı sürdürmek için müşteri kendi başına işi yapmak için endişelenmemelidir.

Bir fotoğraf albümünü ele alırsak, Albümün bir arkadaşlar klasörünün parçasıdır. Müşteri yaratılan albümü aile albümü klasörüne taşımak isterse Sunucu URI lerini albüm kategorisinde, bu taşıma işlemi albümün URI  inde bir değişikliğe neden olur.

Bir kaynağı taşımak, kopyalamaktan çok farklı değildir. Bu durumda sunucu istemcinin bir hedef için kriter sağlamasına izin vermek için bir URI veya URI  şablonu sağlayan bir kaynak oluşturur.

# Request
GET /albums/friends/2020/08/1011 HTTP/1.1
Host: www.example.org

# Response
HTTP/1.1 200 OK
Content-Type: application/xml;charset=UTF-8

<album xmlns:atom="http://www.w3.org/2005/Atom">
   <id>urn:example:album:1011</id>
   <atom:link rel="self" href="http://www.example.org/albums/2020/08/1011"/>
   <link-template rel="http://www.example.org/rels/move"
       href="http://www.example.org/albums/friends/2020/08/1011/move;
                t=dc4128786d463dc7e40c18457d1826fa?group={category}"/>
   <category>friends</category> > Kaynağın kategorisini değiştirmek için URI şablonuna sahip bağlantı..
   ...
</album>

Bu gösterimde sunucu, istemcinin bir kategori belirtmesi ve kaynağın taşınması için bir URI şablonu kullanır.

# Request
POST /albums/friends/2020/08/1011/move;t=dc4128786d463dc7e40c18457d1826fa?
   group=family HTTP/1.1 > Kategoriyi değiştirme talebi

Host: www.example.org
Content-Length: 0

# Response
HTTP/1.1 201 Created
Content-Type: application/xml;charset=UTF-8
Location: http://www.example.org/family/2020/08/1021 > Yeni Kaynak.
Content-Location: http://www.example.org/family/2020/08/1021

<album>
   <id>urn:example:album:1021</id>
   <atom:link rel="self" href="http://www.example.org/family/albums/2020/08/1021"/>
   <category>family</category>
...

Bu isteğin sonucu URI http://www.example.org/albums/ adresinde yeni bir kaynaktır. aile /2020/08/1021

Sunucu, müşteri orjinal albüme erişmeye çalıştığı durumlarda bir 410 veya 4040  döndürebilir.

13 Şubat 2022 Pazar

RestFull WebService - Kaynakların Birleştirilmesi

 

   Kaynakları bileştirmek için uygulamaya özel bir denetleyici kaynak tasarlamak gereklidir. Müşteri alt birleştirilecek kaynakların URI leri veya tanımlayıcıları ile bu URI bir GET isteği uygular, bu işlem için denetleyici sorgu parametleri olarak kullanılır. Sunucu Last-Modified ve ETAG döndürür. Temsilcinin gövdesinde birleştirilecek kaynakların bir özeti ile başlığını içerir. Varlık etiketine bir sıra numarası veya bir zaman damgası rastgele verilir. Özeti doğruladıktan sonra, istemci If-Unmodified-Since ve If-Match bir POST isteğinde bulunur. Birleştirilmeye neden olmak için aynı URI, If-Match başlıkları ile desteklenir.

Birleştirmeden sonra If-Match başlık değeri bir işlem günlüğünden saklar ve URL'in URI içeren bir Konum başlığı ile 201 yanıt kodunu döndürür. Gelecekte bir müşteri aynı If-Match değeri 412 döndürür.

Bir birleştirme sunucuya sunulan iki veya daha fazla kaynağı içerir. Müşterinin iki belgeyi birleştirmenin ayrıntıları sunucuya bırakılmalıdır. Burada müşterinin iki albümü yeni bir albümle birleştirmek için URI alma isteği görünür.

# Request
GET /albums/merge?src=urn%3Aexample%3Aalbum%3A1011&
   dest=urn%3Aexample%3Aalbum%3A1012 HTTP/1.1 > Birleştirilmekte olan kaynakların mevcut durumu alma talebi

Host: www.example.org

# Response
HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Type: application/xml;charset=UTF-8
Last-Modified: Sun, 08 Nov 2020 04:47:03 GMT > Gösterim için Last-Modified ve ETAG 
ETag: "d88a39e41c314f57917da04c920fd608"

<albums> > Birleştirilen kaynakların durumu
 <album>
    <id>urn:example:album:1011</id>
    <atom:link rel="self" href="http://www.example.org/albums/2020/08/1011"/>
    ...
</album>

<album>
   <id>urn:example:album:1012</id>
   <atom:link rel="self" href="http://www.example.org/albums/2020/08/1012"/>
   ...
</album>
</albums>

Bu örnekte, istemci birleştirmek için iki kaynağın tanımlayıcılarını sağlar ve sunucu birleştirilecek kaynakların bir özetini döndürür. Alternatif olarak kullanabileceğiniz birleştirme parametreleri olarak URI lerdir.

 istemci tarafında, önceki yanıttaki albümlerin durumunu müşterinin birleştirme isteği göndermeden önce yerel olarak sahip olduğu ile aynıdır.

# Request
POST /albums/merge?src=urn%3Aexample%3Aalbum%3A1011&
   dest=urn%3Aexample%3Aalbum%3A1012 HTTP/1.1 > kaynak birleştirme isteği

Host: www.example.org
If-Unmodified-Since: Sun, 08 Nov 2020 04:47:03 GMT
If-Match: "d88a39e41c314f57917da04c920fd608" > Önkoşulları

# Response
HTTP/1.1 201 Created
Location: http://www.example.org/albmus/2020/08/1091
Content-Location: http://www.example.org/albmus/2020/08/1091
Content-Type: application/xml;charset=UTF-8
Last-Modified: Sun, 08 Nov 2020 05:30:10 GMT
ETag: "48be3ab269550ee00a84eb5a1a44f330"

<album>
   <id>urn:example:album:1091</id>
   <atom:link rel="self" href="http://www.example.org/albums/2020/08/1091"/>
   ...
</album>

Sunucu, yeni bir birleştirilmiş kaynak oluşturur. Bu işlem sırasında ne olduğuna bağlı olarak sunucunun kullanım durumları talep ederse, sunucu orjinal kaynakları silebilir.

6 Şubat 2022 Pazar

CompTIA Güvenlik Sertifikası için Bilgiler #1


 *    E-Ticaret Web Sitesi sunucusu için günlükler incelenirken, saldırganın web sitesine JavaScript yerleştirerek sulama deliği saldırısı gerçekleştirdiği ortaya çıkmış kullanıcıları  kimlik avı web sitesine yönlendirmekte olduğu bulunmuş. Sorun Çözümü için siteler arasında komut dosyasının çalıştırmanın hemde SQL injection işinin durdurmanın birinci yöntemi kullanıcı girişi kontrol edip filtrelemek.

* Bir hedef değişkene verinin gönderebileceğinden daha fazla veri göndermeye dayanan saldırı türü "Buffer overflow"

* Şİrket ağındaki güvenlik sorunlarını test etmek için Spesifik test ihtiyacı doğmuş ise otomatik ve yarı otomatik araçları kullanarak, ağdaki çeşitli sistemlerdeki bilinen güvenlik açıklarını bulabilmek için en iyi bilinen yol "Vulnerability scan"

* WiFi ağını ihlal eden saldırganı WAP yönetim paneli aracılıyla gönderilen kimlik bilgileri varsayılan yapılandırma örneğidir.

* Saldırgan ağınıza sızdı ve veritabanınızdan verileri çaldı. Tüm Sunucular günlüklerini merkezi bir günlük sunucusuna iletecek şekilde yapılandırılmış. Merkezi günlükleri incelediğimizde iki gün öncesinde sonra hiç bir giriş bulunmuyor. Sunucuları kontrol ettiğimizde doğru sunuculara verilerin gitti öncelikle görülmüş. Ancak kesintiden sonraki verilerin kaybolması ARP zerilenmesi anlamına geliyor. Veriler farklı bir MAC yönlendiren MAC tablolarını değiştirmek için kullanılır.  Neden hiç veri gelmediği bu şekilde açıklanabilir.

* Web Sitesinde oturum açıp ziyaret ettiklerinde web sitesinden düşülüyor. Ağ dışı bilgisayardan denediklerinde de aynı hata alınıyor. Web Sitesi günlükleri kontrol edildiğinde hiç bir kayıt gelmediği görülüyor. "Typosquatting" adlandırılan gerçek Web Sitesine gitmedikleri sahte sunucu üzerinden bağlandıkları tespit edilmiş. 

* Ağ analizi için tehdit analizi oluşturularak geçmiş olaylarda benzer ağlarda bu işlemlere benzer tehditleri ihlal edenleri basitçe yakalamak için düşük seviyeli suç işlemlerinde ve profesyonel olmayan saldırganların tespiti için "Script kiddie" terimi kullanılır.

* Sızma testinde; archive.org, netcraft.com, sosyal medya kaynaklarından toplanan bilgiler için Pasif gerçekte bağlantı kurulmadan yapılan keşif.

* Kurum içindeki satış görevlisinin pc sinde bariz bir yavaşlama sözkonusu kontrol edildiğine ilk önce göze çarpan bir durum söz konusu değil. Ancak geçici klasörler kontrol edildiğinde JPEG dosyalarından çok fazla olduğu görülmüş, Bazı casus yazılımlar sistemden ekran görüntüleri alırlar ve onları internet bağlantısı kurulduğu anda gönderir yada geçici klasörde toplarlar.

* Hedef ağ alan adına sahte girişimlerle giriş yapma işlemine "DNS poisoning" DNS Zehirlenmesi veya etki alanını ele geçirilmesi denir.

* Küçük bir işletme için sızma testi yapılması gerektiğinde test için uzmana şirket adı ve web sitesi alan adı, Ağ Geçici Yönlendiricisi IP si verilmiş. Bu teste "Black-box test" Kara kutu testi minimum bilgi içeren testtir.


23 Ocak 2022 Pazar

Tek Seferlik URI Nasıl Oluşturulur

 

  URI amaçı yeni bir kaynak oluşturmaksa aşağıdakilerden birine dayalı bir belirteç oluşturmamız gerekir. 

Bir sıra numarası veya bir zaman damgası ile rastgele bir sayının birleşimi ile. Bir veya birden fazla kaynağı değiştirmek amaç ise ayrıca varlık etiketlerini ve jetondaki bu kaynak tanımlayıcılar ile birlikte URI kodlamalıyız.

Banka hesabı transfer örneğinde; Transferde bulunmak için sunucunun iki bankanın hesaplarında mevcut durumunun bir işlevi olan URI sağlaması gerekir. Böyle bir URI oluşturabilen kaynak;



# Request

GET /transfer-token?from=urn:example:org:account:1&

   to=urn:example:org:account:2 HTTP/1.1 > Koşullu bir istekte bulunmak için bir URI alma isteği;

Host: www.example.org

# Response

HTTP/1.1 200 OK

Cache-Control: no-cache

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

      rel="http://www.example.org/rel/transfer" > Koşullu URI

<accounts>> Kaynakların mevcut durumu..

   <account>

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

      <balance>200.00</balance>

   </account>

   <account>

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

      <balance>100.00</balance>

   </account>

</accounts

İstekteki kaynaklar jeton dağıtma makinesi gibidir. Müşteri aktarıma dahil olan hesaplar ve sunucular, Transferi başlatmak için URI ile bir bağlantı döndürür. Sunucu ayrıca hesapların mevcut durumunuda içerir.

Müşteri bağlantıyı kullanma kararını geri gönderilen alana dayandırmalıdır. Bu bağlantı yanlızca hesabın mevcut durumu için geçerli  kaynaktır.

Böyle bir URI oluşturmanın bir kaç yolu vardır. Aşağıdaki URI jeton içerir değeri ise rastgele bir sayının birleştirilmesinin bir MD5 karması olan geçerli tarih- iki banka hesabının zaman değeri ve varlık etiketleri:

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


URI kurcalanmasının önlenmesi için URI dijital imzalarıda dahil etmeyin düşünebilirsiniz. Sunucunun daha sonra doğrulama için bu belirteci depolaması gerekmez. Çünkü kaynakların mevcut varlık etikletlerinden jetondan karmalar uyuşmuyorsa sunucu istemci tarafından kullanılan URI artık geçerli olmadığı sonucuna varabilir. Böyle biri zaman belirteçlerine nonce denir. Nonce bir kez kullanılan sayı anlamına gelir.



Yeniden oynatma saldırılarını tespit etmek için tek seferlik URI kullanabilirsiniz. Tekrar saldırıları kötü niyetli bir varlığın isteklerini yakalamak için gizlice dinlenmesi ve yeniden bir gerçek müşteri gibi görünen sponsorlar ve tekrar istekleridir.

Bu tür amaçlar için tek seferlik URI ler kullanırken belirtecin kötü niyetli varlığın tahmin edilmemesi için gelecekteki simge değerleri rastgele oluşturulur.



URI amacı POST kullanarak yeni bir kaynak oluşturmaksa, jetonu oluşturun tarih ve saat değerine ve rastgele bir sayıya dayandırın. Tek seferlik URI yeni bir adres kaynağı oluşturmak için verilebilir. Bu URI deki belirteç bir MD5 karmasıdır. Bu ise rastgele bir sayı ve geçerli saat içerir.


# Request
GET /user/smith/address-token HTTP/1.1 > Bir kaynak oluşturmak için koşullu istekte bulunmak üzere URI alma isteği
Host: www.example.org

# Response
HTTP/1.1 204 No Content
Cache-Control: no-cache
Link: <http://www.example.org/user/smith;t=360e22a55267f0a525b1d49ddc9eed71>;
rel="http://www.example.org/rel/transfer" > Koşullu URI


Bu durumda URI sağlamak için herhangi bir girdi sağlamaya gerek yoktur. Bunu doğrulamak için URI daha önceden kullanılmamışsa sunucunun bir işlem günlüğünde tutması gerekir. Ne zaman istemci POST kullanarak URI oluşturmak için gönderir, öncesinde belirteç sunucudaki bir işlem günlüğünde mevcuttur. Değilse, isteği işleyin.

Web Uygulamaları söz konusu olduğunda belirteci gizli olarak da kodlayabilirisiniz. HTML formlarındaki form alanlarında. 

27 Aralık 2021 Pazartesi

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ı.

12 Aralık 2021 Pazar

Koşullu PUT ve DELETE talepleri Nasıl Gönderilir.

 

İstemci PUT kullanarak yeni bir kaynak oluşturduğunda veya sunucu If Kaynağa yapılan önceki bir GET veya PUT isteğinden beri Değiştirilmiş ve/veya ETAG başlıkları her zamanki gibi PUT isteklerinde bulunur.

İstemcinin önceki bir istekten beri Değiştirildiği Tarih ve/veya ETAG başlıkları varsa kaynak PUT , DELETE istekleri yaparken aşağıdaki başlıkları bu talepli koşullarda eklenir.

* Last-Modified başlığıyla aynı değere sahip bir If-Unmodified-Since başlığı. Sunucunun isteği işlenmesi gerektiğini belirtmek için yanlızca suncuda bu başlıkta belirtilen zamandan beri kaynakta değişiklik yapılmalıdır.

*ETAG başlığıyla aynı değere sahip bir If-Match başlığı sunucu isteği yalnızca ve ancak sağlanan üstbilgi değeri eşlenirse işlemelidir. Mevcut ETAG değeri için belirtilmelidir.

Sunucu 412 (Ön Koşul Başarısız) durum kodunu döndürürse koşulsuz bir yeni Last-Modified ve ETAG başlıklarını almak için GET isteği kaynağının güncellenmesi veya silinmesi kararı yeni temsile göre hala geçerlidir. Sonra bu başlıklarla PUT veya DELETE isteğini tekrar etmeniz gerekir.

Koşullu bir PUT isteğinde bulunan bir istemciye örnek;

# Request
PUT /reviews/notes_from_underground HTTP/1.1
Host: www.example.org
If-Unmodified-Since: Sun, 09 Aug 2019 00:56:14 GMT
If-Match: "3f4a74db207d0447d46710a64971e777"
.....
# Response
HTTP/1.1 200 OK
Date: Sun, 16 Aug 2019 01:00:23 GMT
Content-Location: http://www.example.org/reviews/notes_from_underground
Last-Modified: Sun, 16 Aug 2019 01:00:23 GMT
E-Tag: "5bbae963eb30e03cf1fd218a9dc92a5b"
Content-Type: application/xml; charset=UTF-8
.....

Bu istekte, If-Unmodigied-Since değeri Last-Modified başlığının değeridir. Müşteri önceki bir talep sırasında elde ettiği, benzer şekilde değer If-Match başlığı , ETAG başlığının değeridir. 
Müşteri zaten sahip değilse temsilinin kopyası için veya sunucu yanıt kodunu döndürürse bu başlıklar 412 almak için yeni bir koşulsuz istek GET gönderilmesi gerekir.

# Unconditional GET request
GET /reviews/notes_from_underground HTTP/1.1
Host: www.example.org
Cache-Control: no-cache
Pragma: no-cache
# Response
HTTP/1.1 200 OK
Content-Type: application/xml;charset-UTF-8
Date: Sun, 16 Aug 2019 01:00:23 GMT
Last-Modified: Sun, 09 Aug 2019 00:55:46 GMT
ETag: "3f4a74db207d0447d46710a64971e777"

HEAD talebinde bulunarak bu başlıkları elde etmek yeterli değildir. İstemciler bu başlıklar kaynağın mevcut durumuna karşılık gelir. Başlıkları bir HEAD isteği araclığıyla tek başına almak, müşterinin bunu bilmesine yardımcı olmayacaktır. Kaynağın mevcut durumu, body nin onunla birlikte alınması gerekir. Üstbilgiler dahil.


İstemci DELETE istekleri için aynı süreci izlemelidir. 412 herhangi bir istek istemcinin güncelleme veya silme kararı verdiğini gösterir.


# Conditional request
PUT /reviews/notes_from_underground HTTP/1.1
Host: www.example.org
If-Unmodified-Since: Sun, 09 Aug 2019 00:56:14 GMT
If-Match: "3f4a74db207d0447d46710a64971e777"
# Response
HTTP/1.1 412 Precondition Failed

Content-Type: application/xml;charset=UTF-8
<error>
   <message>The review you are trying to update has changed.</message>
   <description>You are trying to update a resource based on stale information.
   Get a new copy of this review, resolve any differences, and retry.</description>
</error>

9 Aralık 2021 Perşembe

Müşteriden Koşulsuz GET Talepleri Nasıl Yapılır

  HTTP 1.1 istemcilerin sona erme önbelleğini değiştirmesine ve yeni temsiller istemesine izin verir. Bu tarif bir kaynak aldıktan sonra bir kayanağın yeni bir temsilini almak için kullanabilirsiniz. 412 (Ön Koşul Başarısız ) veya en yenisini almak için başarılı bir PUT veya PATCH den sonra  bile oluşan temsildir. 

GET isteğinde; Cache-Control : non-cache ve Pragma: non-cache üst bilgilerini ekleyin.

İstemcinin bir kaynağı güncellemek için koşullu bir PUT isteğinde bulunduğunu varsayalım.  Katmanlı koşullar eşleşmiyor ve sunucu 412 yi döndürüyorsa.

# Process this request if and only if the included conditional tags match

PUT /reviews/notes_from_underground HTTP/1.1

Host: www.example.org

If-Unmodified-Since: Sun, 09 Aug 2019 00:56:14 GMT

If-Match: "3f4a74db207d0447d46710a64971e777"

...

# Response

HTTP/1.1 412 Precondition Failed

Content-Length: 0


Müşteri artık yeni bir temsil almak için koşulsuz  kaynağından bir GET talebinde bulunabilir. 

# Request
GET /status HTTP/1.1
Cache-Control: no-cache> Önbellek kontrolü: önbelleksiz ve Pragma önbelleksiz üstbilgiler, istemci koşullu isteklerini ortadan kaldırır.
Pragma: no-cache

# Response
HTTP/1.1 200 OK
Date: Sun, 09 Aug 2019 05:20:10 GMT
Last-Modified: Sun, 09 Aug 2019 05:20:10 GMT > Sunucu uygulanabilir değiştirilmiş. Last-ETAG
ETag: "a3d3005f4a1632c88e8889af985e6294"
Expires: Sun, 09 Aug 2019 15:56:14 GMT
Cache-Control: max-age=36000,public
Content-Type: application/xml; charset=UTF-8
...


İstekleri non-cache yönergesi herhangi bir ara önbellekten önbelleğe sunmamasını ister. Temsil eder ve isteği kaynak sunucuya iletir.

Bazı önbelleklerin önbellek yok yönergesi sayacak şekilde yapılandırabildiğini unutmayalım. Böyle durumlarda önbellekler bir UYARI başlığı döndürebilir. 

# Request
GET /status HTTP/1.1
Cache-Control: no-cache
Pragma: no-cache
# Response
Date: Sun, 09 Aug 2019 00:56:14 GMT
Last-Modified: Sun, 09 Aug 2019 00:56:14 GMT
Expires: Sun, 09 Aug 2019 10:56:14 GMT
Cache-Control: max-age=36000,public
Content-Type: application/xml; charset=UTF-8
Age: 1021
Warning: 110



Warning başlığının değeri bir tamsayı kodudur ve bu örnekte şunu belirtir. Yanıt eski, bu başlıkla ilgili daha fazla ayrıntı için HTTP 1.1 e göz atmanız gerekir. 

NOT:
Gerekmedikçe koşulsuz GET talepleri yapmayın. Koşulsuz istekler performansı düşürür ve gecikmeyi artırır.


31 Ekim 2021 Pazar

Sunucuda Koşullu DELETE İstekleri Nasıl Uygulanır

   Koşullu Delete istekleri, istemcilerin kaynaklarını silmelerini engellemeye yardımcı olabilir. Örneğin, istemci bir kullanıcı kullanıcı kaynağını silmek istemeyebilir. İstemci kullanıcının "inaktif" den "aktife" değiştirir. 

Şimdi DELETE istekleri için eşzamanlılık denetiminin nasıl olduğuna kısaca bakalım.

İstemci koşulsuz bir DELETE isteği gönderirse, 403 hata kodunu döndürür. Verilen koşullar uyuşmuyorsa 412 hata kodunu (Başarısız) döndürür. Her iki durumda da,  sorunun durumunu  temsili olarak açıklayın.  İstemciler koşullu bir DELETE talebi gönderirse ve sağlanan koşullar eşleşirse, kaynağı silin. 

Sunucunun yapması gereken kontrollere genel bir bakış için aşağıdaki akışı bakabiliriz.


Bir müşteri silinmeye hazır olduğunu varsayarak bir kaynağı  silmeye karar verebilir. İçinde bu arada başka bir müşteri aynı kaynağı güncelleyerek ilk müşterinin varsayımsal olarak koşullu DELETE kullanma durumu bunu önler. DELETE isteği koşullu olduğunda sunucu istemcinin silme kararını doğrulayabilir. Kaynak en son duruma bağlıdır. Sunucu bu işi şu şekilde yapar. 

İstemci tarafından sağlanan If-Unmodified-Since ve If-Match başlıkları bunların şimdiki değerleri.

# Process this request if and only if the included conditional tags match

DELETE /reviews/notes_from_underground HTTP/1.1

Host: www.example.org

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

If-Match: "3f4a74db207d0447d46710a64971e777"

# Response

HTTP/1.1 204 No Content

14 Mayıs 2021 Cuma

Sunuculardaki Koşullu PUT İstekleri


PUT istekleri için uygulama veya eşzamanlılık kontrolünün güncellemelerde olmaması, Last-Modified ve/veya ETAG başlıklarında nasıl uygulanacağını gösterilecektir. Kaynak henüz mevcut değilse ve sunucu PUT aracılıyla kaynak oluşturmayı destekliyorsa, istemci tarafından belirtilen URl de yeni bir kaynak oluşturun. Sunucu desteklemiyorsa kaynak oluşturma, istemciye 404 durumunu döndürün. 


Kaynak varsa aşağıdaki adımları uygulayalım.

* İstemci If-Unmodified-Since ve/veya If-Match üstbilgilerini içermiyorsa döndür, 403  cevap gövdesinde nedenini açıklayın.
* Sağlanan If-Unmodified-Since veya If-Match başlıkları gerçek sunucudaki gösterimin değiştirilmiş tarih-saat ve ETAG değerleri hata döndürürse. Kod 412 (Ön koşul başarısız)
*İstemci koşullu bir PUT isteği gönerirse ve sağlanan koşullar eşleşir kaynağı günceller ve 200 (OK) veya 204 (İçerik Yok) geri dönüş sağlanır.
İsteğe bağlı olarak, sağlanan güncellenmiş Son Değiştirilmiş ve/veya ETAG başlıklarını eklenebilir. Kaynak yanıt aynı zamanda güncellenen URI ile bir Content-Location başlığı içerir.

Sunucunun yapması gereken kontrollere genel bir bakış için.





Bunun işe yaraması için her zaman Last-Modified ve/veya ETAG başlıklarını eklediğinizden emin olun. Çünkü Sunucu istemciye bir temsil döndürür.


Koşullu PUT isteklerini uygulama adımları, koşullu PUT isteklerini uygulamaya benzer GET istekleri  için bir sonraki makalede ele alınacaktır.  Temel fark If-Unmodified-Since kullanılmasıdır. ve/veya If-Match-Since ve/veya If-None-Match başlıkları yerine If-Match başlıkları kullanılabilir.

Bir müşteri tarafından gönderilen PUT isteği;


# Process this request if and only if the included conditional tags match
PUT /reviews/notes_from_underground HTTP/1.1
Host: www.example.org
If-Unmodified-Since: Sun, 09 Aug 2020 00:56:14 GMT
If-Match: "3f4a74db207d0447d46710a64971e777"

Sunucu koşullu üstbilgiler bekleniyorsa ancak istek hiçbirini bulamazsa dönüş yanıt kodu 403 olarak geri dönüş yapılabilir. İstek koşullu başlıklar bulursa, bunları Last-Modified ve/veya ETAG değerlerinin mevcut değerleri ile karşılaştırılmalıdır. Eğer onlar eşleşirse, sunucu güncellemeyi işleyebilir. 200 (OK) yanıtı döndürebilir. Değilse; sunucu dönüş yanıt kodu 412 (Ön Koşul Başarısız) döndürebilir. Bazı örnekler için bir sonraki makalelerde yer verilecektir.

Suncu istekleri üzerine hem son değiştirilmiş hemde ETAG üst bilgileri gönderirse, PUT isteğini yanlızca If-Unmodified-Since ve If-Match başlıkları mevcut değerlerle eşleşir.  İçlerinden biri başarısız olsa bile MATCH 412 döndürülür.

İşte PUT isteklerini koşullu yapmanın neden önemli olduğunu gösteren bir örnek; İstemcilerin değiştirilebileceği ve/veya içeriği yöneten wiki benzeri bir sunucu düşünün. İçeriği silin. Değiştirilmek isteyen A ve B olmak üzere iki müşteri olduğunu varsayın. Aşağıdaki sırayla bir kaynak istemci A kaynağın bir temsilini alır. A istemcisinin bir kullanıcısı, kaynağı yerel olarak bir metin düzenleyicisinde düzenlemeye başlar.

# Request from client A
GET /reviews/notes_from_underground HTTP/1.1
Host: www.example.org
# Response
HTTP/1.1 200 OK
Content-Type: application/xml;charset-UTF-8
...


Müşteri B aynı kaynağın bir temsilini alır ve B istemcisinin bir kullanıcısı yerel olarak düzenlemeye başlar. 

# Request from client B
GET /reviews/notes_from_underground HTTP/1.1
Host: www.example.org
# Response
HTTP/1.1 200 OK
Content-Type: application/xml;charset-UTF-8

B istemcisinin kullancısı düzenlemlerini tamamlar ve bir PUT isteğinde bulunarak değişikliği sunucuya gönderir.

# Request from client B
PUT /reviews/notes_from_underground HTTP/1.1
Host: www.example.org
HTTP/1.1 200 OK
Content-Type: application/xml;charset-UTF-8

İLK GÜNCELLEME:
Bir kaç saniye sonra A istemcisinin kullanıcısı düzenlemelerini bitirir ve değişiklikleri  ile birlikte gönderir. Başka bir PUT isteği;

# Request from client A
PUT /reviews/notes_from_underground HTTP/1.1
Host: www.example.org

# Response
HTTP/1.1 204 OK
Content-Type: application/xml;charset-UTF-8

ikinci güncelleme ilk güncellemenin üzerine yazar.

Bu sıranın bir sonucu olarak, A müşterisi, B müşterisi tarafından yapılan değişikliklerin üzerine yazar. İstemci B'nin güncellemesi kaybolur.! ne müşteri A nede müşteri B de kayıp güncellemeden haberi yoktur.
Her iki PUT işlemi sonuçta başarılı oldu. Ancak daha sonra B'nin kullanıcısı güncellemelerinin kaybolduğunu görecektir. Her değişikliği kaydetmek için sunucuda uygulamazsanız bu kayıp güncelleştirmeyi algılamak için sunucuda hatayı ayıklayamazsınız.

PUT isteklerini koşullu yapmak güncelleme kaybını önler. Gelen bir istek müşteri B için;

# Request from client B
PUT /reviews/notes_from_underground HTTP/1.1 >> İlk koşullu güncelleme başarılı
Host: www.example.org
If-Unmodified-Since: Sun, 09 Aug 2020 00:56:14 GMT
If-Match: "3f4a74db207d0447d46710a64971e777"

# Response
HTTP/1.1 204 No Content
Content-Location: http://www.example.org/reviews/notes_from_underground
Content-Type: application/xml;charset-UTF-8
Last-Modified: Sun, 09 Aug 2020 01:10:14 GMT
If-Match: "5dcb920acfd4f3943dbc1672756d7f43"

İlk koşullu güncelleme başarılı ;
Yanıt bir Content-Location başlığı ve güncellenmiş Last-Modified ve istemcinin gelecekteki isteklerde kullanabileceği ETAG değerleri.

İstemcinin isteği koşulluysa ve sunucu istemcinin isteği çatışmaları doğru bir şekilde tanımlayabilir.

# Request from client A
PUT /reviews/notes_from_underground HTTP/1.1 > 2 nci güncelleme Failed etti. 
Host: www.example.org
If-Unmodified-Since: Sun, 09 Aug 2020 00:56:14 GMT

If-Match: "3f4a74db207d0447d46710a64971e777"
# Response
HTTP/1.1 412 Precondition Failed
Content-Type: application/xml;charset-UTF-8
<error>

   <message>The review you are trying to update has changed.</message>
   <description>You are trying to update a resource based on stale information.
   Get a new copy of this review, resolve any differences, and retry.</description>
</error>



1 Mayıs 2021 Cumartesi

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.