· kaynak dev.to (home feed)
nginx yeni HTTP QUERY metodunu geçiriyor ama önbelleğleyemiyor
RFC 10008, gövdeli ve önbelleklenebilir bir GET olan QUERY metodunu standartlaştırıyor; dev.to'daki uygulamalı bir test, nginx'in QUERY isteklerini hiç dokunmadan proxy'lediğini ama önbellek katmanının yanıtları depolamayı reddettiğini gösteriyor.

Web'in yeni bir HTTP metodu var. Haziran'da IETF tarafından yayınlanan RFC 10008 ile standartlaştırılan QUERY, salt okunur isteklerin parametre taşıma biçimindeki uzun süredir devam eden bir boşluğu gidermeyi amaçlıyor. dev.to'daki uygulamalı bir yazı, çevresindeki altyapının ancak yarı hazır olduğunu ortaya koyuyor: en yaygın dağıtılan reverse proxy'lerden biri olan nginx, QUERY isteklerini hiç itiraz etmeden iletiyor, ancak önbellek katmanı metodu tamamen reddediyor ve bu da QUERY'nin var olmasındaki temel nedeni geçersiz kılıyor.
QUERY ne işe yarıyor
dev.to yazısına göre QUERY, istek gövdesi taşımasına izin verilen bir GET gibi davranıyor. Güvenli ve idempotent, önbelleklenebilir; RFC bir de şart ekliyor: gövdenin içeriği ne olursa olsun önbellek anahtarına yansıtılmalı. Bunu motive eden durum, parametrelerinin URL'e mantıklı bir şekilde sığmayacak kadar büyük ya da kullanışsız olduğu okuma istekleri. Bugün bu istekler POST olarak gidiyor ve pratikte downstream tarafındaki hiçbir şey yanıtı önbelleğlemiyor.
Test düzeneği
Çevresindeki mekanizmaların gerçekte ne kadar hazır olduğunu görmek için yazar, yalnızca QUERY'ye yanıt veren, 9.836 girdilik RFC dizini üzerinden bir arama API'si kurdu. Diğer herhangi bir metod 405 alıyor ve Allow başlığında QUERY belirtiliyor. Bu katılık bilinçliydi: POST'u da tolere eden bir sunucu, ilginç hataları sessizce yutacaktı.
Yazının büyük kısmı, bu endpoint'i dil modellerine yönelten bir deney. Prompt açıkça QUERY ve RFC 10008 dediğinde, yazarın erişebildiği sekiz modelin tümü çalışan istemciler üretti; örneğin Python'ın urllib'ü herhangi bir dizeyi metod argümanı olarak kabul ediyor. Prompt metodu belirtmediğinde ise sekizi de varsayılan olarak POST'u seçti ve hiçbiri önce bir OPTIONS sorgusu denemedi. Tam 405 yanıtı gösterildiğinde yalnızca sekiz modelden dördü doğru şekilde QUERY'ye geçti. Biri QUERY kullandı ama filtreleri URL'e taşıyıp boş bir gövde göndererek metodun çözdüğü sorunun ta kendisini çöpe attı; bir diğeri, aynı sunucunun az önce reddettiği GET'i denedi. İki model, istenmeden, 405'i yakalayıp Allow başlığında adı geçen metotla yeniden deneyen istemciler yazmıştı. İlginç; ama yazarın daha önemli bulgusu stack'in bir katman aşağısında duruyor.
nginx'in durduğu yer
Proxying çalışıyor: API'nin önünde nginx varken her QUERY isteği hiç dokunulmadan geçiyor. Önbellekleme çalışmıyor. proxy_cache_methods yönergesi GET, HEAD ve POST kabul ediyor ve liste genişletilemiyor. Orada QUERY belirtmek sunucunun başlamasını engelliyor; yazarın nginx -t çalışması, yönerge için geçersiz değer olarak QUERY'yi gösteren bir hatayla başarısız oluyor.
Bariz geçici çözüm de incelikli bir nedenle başarısız oluyor. Metodu upstream tarafında proxy_method POST ile yeniden yazıp POST'u önbelleklenebilir ilan edebilirsiniz, ama nginx proxy_cache_methods değerlendirmesini iletildiği metoda değil, istemcinin gerçekten gönderdiği metoda göre yapıyor. Yazar bunu, konfigürasyonu ve istek gövdesini sabit tutup yalnızca iletimdeki metodu değiştirerek doğruladı: QUERY olarak gönderilen dört isteğin tamamı backend'e ulaşırken önbellek hiçbir şey yapmadı; POST olarak gönderilen dört istekten ise yalnızca biri backend'e ulaştı ve üçü önbellekten sunuldu. nginx'in harekete geçmediğine dair ipucu veren bir cache-status başlığı bile yok.
Uygulayıcılar için bir tuzak daha
Yazı ayrıca yol boyunca keşfedilen sunucu tarafı bir tuzak da belgeliyor. Node'un http modülü, hakkında görüş belirtmediği bir metod için Content-Length belirlemiyor ve bunun yerine chunked transfer encoding'e başvuruyor. Yalnızca Content-Length okuyan bir sunucu boş bir gövde görüyor, ardından keep-alive bağlantısı yeniden kullanıldığında okunmamış chunk'lar üzerine takılıp istemci hatası gibi görünen kafa karıştırıcı parse hataları üretiyor. QUERY sunucusu yazan herkes chunked gövdeleri işleyebilmeli.
Neden önemli
QUERY, dağıtım yapanların iletimde gerçekten karşılaşacağı nadir web platformu değişikliklerinden biri ve erken tablo dengesiz. Yalnızca byte taşıyan stack katmanları — standart kütüphaneler, istemciler ve proxy'ler — esasen hazır, önbellekleme altyapısı ise değil. dev.to yazarının ironiyi çerçevelediği gibi, RFC'nin önbelleklenebilir olması için tasarladığı metod, internetin büyük bölümünün üzerinde çalıştığı proxy tarafından önbelleklenemiyor; hiçbir zaman önbelleklenmesi amaçlanmamış olan POST ise önbelleklenebiliyor. Bugün nginx arkasında QUERY benimseyen ekipler semantik faydaları elde ediyor ama önbellekleme getirisinden hiçbirini almıyor ve nginx, proxy_cache_methods'un kabul ettiği metod kümesini genişletene kadar, görünür bir başarısızlık yerine sessiz bir önbelleklememe durumu beklemeliler.
- #nginx
- #http
- #caching
- #web-standards
- #proxy