Blog

Durum Kodu 102 Processing Nedir? Sunucudan Devam Ediyorum Sinyali

INEZA Felin-Michel

INEZA Felin-Michel

10 September 2025

Durum Kodu 102 Processing Nedir? Sunucudan Devam Ediyorum Sinyali

Kurumsal İçin Apidog

Şirket İçi (On-Premises) Dağıtım

SSO ve RBAC

SOC 2 Uyumlu

Apidog Enterprise'ı Keşfedin

Buluta devasa, çok gigabaytlık bir video dosyası yüklüyorsunuz. İlerleme çubuğu yavaşça sürünüyor. Birdenbire tarayıcınız donuyor. Sayfa yanıt vermiyor gibi görünüyor. Birkaç endişeli dakikanın ardından, korkunç bir hata alıyorsunuz: 504 Gateway Timeout. Sunucu sizi yarı yolda bıraktı.

Şimdi farklı bir senaryo hayal edin. Yükleme aynı derecede yavaş, ancak sayfadaki küçük dönen bir gösterge aktif. Bir bildirim alıyorsunuz: "Videonuz işleniyor... bu birkaç dakika sürebilir." Sabırla beklersiniz ve sonunda bir başarı mesajı alırsınız.

Fark neydi? İkinci senaryoda, sunucu beklentilerinizi yönetmek için akıllıca, nadir de olsa, bir HTTP durum kodu kullanmış olabilir: 102 Processing.

Bu durum kodu, sunucunun nazikçe şöyle demesinin bir yoludur: "Hey, isteğinizi aldım. Bu büyük bir istek ve bitirmem biraz zaman alacak. Ama hala yaşıyorum ve üzerinde çalışıyorum, bu yüzden lütfen telefonu kapatmayın!"

Bu, mutfak karmaşık bir yemek hazırlarken garsonun masanıza uğramasının dijital karşılığıdır. Henüz yemeğinizi getirmiyorlar, ancak siparişinizin unutulmadığına dair sizi temin ediyorlar.

Web geliştirme veya API entegrasyonlarıyla ilgileniyorsanız, HTTP durum kodlarına, özellikle 200 OK veya 404 Not Found gibi popüler olanlara göz atmış olabilirsiniz. Ancak, 102 Processing gibi daha az bilinen ama eşit derecede önemli kodlar da mevcuttur. Yaygın olarak anlaşılmasa da, bu HTTP durumu, özellikle karmaşık veya uzun süren istekleri ele alırken istemciler ve sunucular arasındaki iletişim verimliliğini artırmaya yardımcı olur.

İlk bakışta kafa karıştırıcı gelebilir. "İşleme" tam olarak nedir? Sunucu neden bu mesajı göndermek zorunda kalsın ki? Ve en önemlisi, geliştiriciler bunu gerçek dünya uygulamalarında nasıl ele almalı?

İşte bu kılavuzda tam da bunu keşfedeceğiz.

Bu kapsamlı blog yazısında, 102 Processing durum kodunun ne anlama geldiğini, neden tanıtıldığını, nasıl çalıştığını ve hangi senaryolarda kullanıldığını keşfedeceksiniz. 102 Processing gibi nadir olanlar da dahil olmak üzere HTTP durum kodlarını test etmek istiyorsanız, güvenilir bir API test platformuna ihtiyacınız var. İşte bu noktada Apidog devreye giriyor. Apidog ile API'leri sorunsuz bir şekilde tasarlayabilir, taklit edebilir, test edebilir, hata ayıklayabilir ve belgelendirebilirsiniz, tüm bunları yanıtları gerçek zamanlı olarak incelerken yapabilirsiniz. Ve en iyi yanı ne mi? Apidog'u bugün ücretsiz indirebilir ve 102 Processing gibi kodları uygulamalı olarak keşfetmeye başlayabilirsiniz.

button

Şimdi, HTTP 102 Processing durum kodunun amacını, geçmişini ve pratik uygulamasını keşfedelim.

Sorun: Sabırsız İnternet

İnternet sabırsızlık üzerine kurulmuştur. HTTP bağlantılarının sonsuza kadar açık kalması amaçlanmamıştır. İstemciden (tarayıcınız) potansiyel proxy'lere ve yük dengeleyicilere kadar zincirdeki her bileşenin yerleşik zaman aşımları vardır.

Bir sunucu yanıt göndermek için çok uzun sürerse, bu bileşenler bağlantının öldüğünü varsayacak ve onu sonlandıracak, bu da genellikle aşağıdaki gibi hatalara yol açacaktır:

Bu mantıklı bir güvenlik önlemidir. Asılı kalan bağlantıların değerli kaynakları tüketmesini engeller. Ancak, büyük bir videoyu işlemek, karmaşık bir rapor oluşturmak veya toplu veri işlemi gerçekleştirmek gibi tamamlanması uzun zaman alan meşru işlemler için bir sorun yaratır.

Soru şudur: Bir sunucu, nihai yanıtı göndermeden istemciye "Hala çalışıyorum" mesajını nasıl iletir?

RFC 2518'de (WebDAV için) tanımlanan yanıt, 102 Processing durum kodudur.

102 Processing Durum Kodu Nedir?

HTTP durum kodu 102 Processing, 1xx Bilgilendirme yanıt sınıfına aittir. Bu durum kodları nihai yanıtları temsil etmez; bunun yerine, istek-yanıt yaşam döngüsü sırasında ek bilgi sağlarlar.

Özellikle, 102 Processing şu anlama gelir:

"Sunucu isteğinizi aldı ve aktif olarak üzerinde çalışıyor, ancak henüz nihai bir yanıt mevcut değil."

Bu durum kodu RFC 2518'de (HTTP'ye WebDAV uzantısı) tanımlanmıştır. Esas olarak istemciye şunları bildirmek için tasarlanmıştır:

Başarı veya başarısızlığı bildiren tipik yanıt kodlarının aksine, 102, istemciyi bilgilendirmek ve uzun süreli isteklerde erken zaman aşımlarını önlemek için bir yoldur.

WebDAV Bağlantısı

102 Processing'i anlamak için WebDAV'dan (Web Dağıtılmış Yazma ve Sürümleme) bahsetmeniz gerekir. WebDAV, istemcilerin uzak bir web sunucusunda dosyaları işbirliği içinde düzenlemesine ve yönetmesine olanak tanıyan bir HTTP uzantısıdır. Windows veya macOS'ta eşleyebileceğiniz "ağ sürücüleri"nin arkasındaki teknolojidir.

Binlerce dosya içeren bir klasörü kopyalama veya taşıma gibi WebDAV işlemleri çok uzun sürebilir. 102 durum kodu, bu uzun süreli işlemler sırasında bağlantıyı canlı tutmak için özel olarak bu bağlamda icat edilmiştir.

102 Processing Neden Var?

Modern web istekleri, özellikle işleme şunları içerdiğinde, genellikle karmaşık ve zaman alıcı olabilir:

Büyük bir dosya yüklediğinizi veya bir API aracılığıyla karmaşık bir veritabanı işlemi çalıştırdığınızı hayal edin. Sunucu yanıt vermek için çok uzun sürerse, istemci bir şeylerin ters gittiğini düşünebilir ve bağlantıyı kesebilir.

İşte bu noktada 102 Processing devreye girer.

İstemciye şunu söyler: "Rahat ol, isteğini aldım. Zaman alıyor ama üzerinde çalışıyorum."

Bu özellikle şunlarda yardımcı olur:

102 tanıtılmadan önce, istemciler bir isteğin sadece yavaş mı yoksa kayıp mı olduğunu bilmiyorlardı, bu da genellikle gereksiz yeniden denemelere veya bağlantı zaman aşımlarına yol açıyordu. 102 kodu bir kalp atışı gibi davranır ve istemcilere şunu söyler: "Bekle, üzerinde çalışıyorum!"

WebDAV'da 102'nin Rolü

102 Processing başlangıçta WebDAV'da (Web Dağıtılmış Yazma ve Sürümleme) tanıtıldı, bu da işbirliğine dayalı dosya yönetimi için HTTP'yi genişletir.

Örneğin, bir kullanıcı 500 MB'lık bir dosya yüklerse:

WebDAV ana itici güç olsa da, 102 modern REST API'lerinde ve ağır iş yükleriyle uğraşan bulut hizmetlerinde de yararlı olabilir.

100 Continue ve 102 Processing Arasındaki Farklar

102'nin benzer 100 Continue'dan nasıl farklı olduğunu merak ediyor olabilirsiniz:

Birlikte, bu durum kodları karmaşık istek döngüleri sırasında iletişim verimliliğini artırır.

Nasıl Çalışır: İletişim Akışı

102 Processing yanıtının işleyişine dair varsayımsal bir örneği inceleyelim.

Senaryo: Bir istemci sunucuya "panoramik fotoğraf oluşturmak için tüm yüklenen resimleri işle" der. Bu, 90 saniye sürecek CPU yoğun bir görevdir.

İstek:

İstemci /api/generate-panorama adresine bir POST isteği gönderir.

Anında (102) Yanıt:

Sunucunun API'si isteği alır ve doğrular. İşin biraz zaman alacağını bilir. Sessiz kalmak yerine, hemen geri gönderir:

HTTP/1.1 102 Processing

Bu yanıtın gövdesi yoktur. Sadece bir durum satırı ve başlıklardan oluşur. Tek işi "Üzerinde çalışıyorum" demektir.

Bekleme Süresi:

İstemci 102 kodunu alır. İyi huylu bir istemci bunun bağlantıyı açık tutması ve beklemeye devam etmesi gerektiği anlamına geldiğini anlar. İstemcinin zaman aşımı sayacı etkili bir şekilde sıfırlanır.

Nihai Yanıt:

Doksan saniye sonra, sunucu panoramayı oluşturmayı bitirir. Şimdi aynı bağlantı üzerinden gerçek yanıtı gönderir:

HTTP/1.1 200 OKContent-Type: application/json
{"status": "success", "url": "/images/panorama-123.jpg"}

İstek-yanıt döngüsü şimdi tamamlandı.

Bu basit "canlı tutma" sinyali, ağ ekipmanının ve istemcilerin sunucunun öldüğünü yanlışlıkla düşünmesini engeller.

102 Processing Neden Daha Yaygın Değil?

Bu kadar kullanışlıysa, çoğu geliştirici neden onu hiç görmedi veya kullanmadı? Birkaç önemli nedeni var:

Asenkron Desenlerin Yükselişi: Uzun süreli istekler için modern çözüm, 102 Processing'den genellikle daha iyidir. Bir bağlantıyı dakikalarca açık tutmak yerine, en iyi uygulama artık şudur:

Bu desen daha ölçeklenebilirdir. Uzun süreli görevleri beklerken değerli sunucu süreçlerini veya bağlantılarını meşgul etmez.

Sınırlı İstemci Desteği: 102 Processing'in çalışması için istemcinin onu nasıl işleyeceğini bilmesi gerekir. Tüm HTTP istemcileri ve kütüphaneleri, tek bir bağlantıda birden fazla yanıt beklemek veya doğru yorumlamak için inşa edilmemiştir. Sorgulama ile asenkron desen evrensel olarak anlaşılır.

Tüm Sorunları Çözmez: Bir 102 yanıtı, bağlantı için zaman aşımını sıfırlar, ancak herhangi bir ilerleme güncellemesi sağlamaz. İstemci, işin %1'inin mi yoksa %99'unun mu bittiği konusunda hala karanlıkta kalır. Sorgulama deseni, durum yanıtında bir ilerleme alanı sağlar.

102 Processing'in Uygulamalı Örneği

Bunun pratikte nasıl görünebileceğine bakalım.

İstemci İsteği:

PUT /files/large-video.mp4 HTTP/1.1
Host: example.com
Content-Length: 600000000

Sunucu Yanıtı (hala çalışırken):

HTTP/1.1 102 Processing

Nihai Sunucu Yanıtı (işlem bittiğinde):

HTTP/1.1 201 Created
Location: /files/large-video.mp4

Burada, 102 yanıtı, nihai 201 Created gelmeden önce ilerlemenin devam ettiğini istemciye garanti eder.

Modern Kullanımlar ve Alternatifler

Saf 102 Processing nadir olsa da, çözdüğü sorun nadir değildir. Modern web, daha sağlam ve ölçeklenebilir başka stratejiler benimsemiştir:

  1. 202 Accepted + Sorgulama: Yukarıda açıklandığı gibi, bu günümüzde en yaygın ve ölçeklenebilir desendir.
  2. Sunucu Tarafından Gönderilen Olaylar (SSE): Sunucunun ilerleme güncellemelerini göndermek istediği uzun süreli işlemler için, SSE, sunucunun istemciye birden fazla olay göndermesi için tek yönlü bir kanal sağlar.
  3. Web Kancaları (Webhooks): Nihai ayrıştırma. Sunucu işi işler ve ardından istemci tarafından sağlanan bir URL'ye (bir web kancası) bir geri arama göndererek tamamlandığını bildirir.

Ancak, 102 Processing hala belirli senaryolarda, özellikle dahili API'lerde veya sistemlerde faydalı bir araç olabilir:

Gerçek Dünya Kullanım Durumları

Gerçek hayatta 102 Processing ile nerede karşılaşabilirsiniz?

102 Processing Aldığında İstemciler Ne Yapmalı?

102 yanıtı tamamen bilgilendiricidir, bu nedenle istemciler genellikle:

Çoğu modern HTTP istemcisi 102'yi sorunsuz bir şekilde işler veya göz ardı eder, çünkü işlemi sonuçlandırmaz.

102 Processing'in Kullanıcı Deneyimi ve Performans Üzerindeki Etkisi

102 erken zaman aşımlarını önlemeye yardımcı olsa da, karmaşıklık katabilir:

102 Processing'in Faydaları

102 Processing ile neden uğraşalım ki?

Yaygın Sorunlar ve Tuzaklar

Yararlı olsa da, birkaç uyarı var:

Apidog ile API'leri Test Etme

102 Processing gibi durum kodlarıyla çalışırken, bunları doğru bir şekilde test etmek çok önemlidir, ancak 102 Processing kullanan API'leri test etmek, asenkron ve çok aşamalı yanıtlar nedeniyle zor olabilir.

İşte bu noktada Apidog gerçekten parlıyor:

button

API geliştirme konusunda ciddiyseniz, Apidog nadir durum kodlarında hata ayıklamayı zahmetsiz hale getirir. Apidog'u ücretsiz indirin ve karmaşık 102 Processing iş akışlarını ele alanlar da dahil olmak üzere API testlerinizi ustaca yönetin.

Geliştiriciler İçin En İyi Uygulamalar

İşte 102 Processing ile çalışırken bazı ipuçları:

Sonuç: Modern Dünyada Niş Bir Araç

Peki, 102 Processing durum kodu nedir?

Kısacası, sunucudan gelen bir sinyaldir ve şöyle der:

"İsteğinizi aldım ve üzerinde çalışıyorum. Henüz vazgeçmeyin!"

Özellikle sessizliğin istemcinin bir hata olduğunu varsaymasına neden olabileceği uzun süreli istekler için değerlidir. Diğer kodlar kadar yaygın olmasa da, doğru senaryolarda güçlü bir araçtır.

HTTP 102 Processing durum kodu, web geliştirmenin belirli bir zamanının büyüleyici bir kalıntısıdır ve WebDAV protokolündeki acil bir sorunu çözmek için tasarlanmıştır. Daha ölçeklenebilir asenkron desenlerle büyük ölçüde yerini almış olsa da, HTTP spesifikasyonunun geçerli ve bazen kullanışlı bir parçası olmaya devam etmektedir.

102 Processing'i anlamak, ağ programlamasının zorlukları ve API tasarımının evrimi hakkında daha derin bir içgörü sağlar. Senkron basitlik ile asenkron ölçeklenebilirlik arasındaki sürekli gerilimi vurgular.

Çoğu modern uygulama için, sorgulama veya web kancaları ile 202 Accepted deseni üstün bir seçimdir. Ancak 102'nin var olduğunu bilmek, bilinçli bir mimari karar vermenizi sağlar. Ve uzun süreli API davranışını test etmeniz gerektiğinde, 102, 202 veya başka herhangi bir durum kodunu kullanıyor olsun, Apidog gibi güçlü bir araç kullanmak, isteğin ne kadar sürdüğüne bakılmaksızın sorunsuz ve güvenilir bir kullanıcı deneyimi sağlamak için ihtiyacınız olan kontrolü ve görünürlüğü sağlayacaktır; istekleri simüle edebilir, ara yanıtları kontrol edebilir ve API'lerde profesyonel gibi hata ayıklayabilirsiniz.

Sadece okumakla kalmayın, Apidog'u ücretsiz indirin ve bugün denemeye başlayın.

button

API Tasarım-Öncelikli Yaklaşımı Apidog'da Uygulayın

API'leri oluşturmanın ve kullanmanın daha kolay yolunu keşfedin

Ücretsiz Kaydolİndir