AI aracı yönlendirildiğinde POST gövdesi yeniden gönderilir mi?

Yeni adres isteğin anlamını değiştirebilir

AI ajanı bir araca POST isteği gönderiyor. Araç başka bir adrese yönlendiriyor; son yanıt 200 olduğu için ajan işlemi doğru tamamlanmış sayıyor. Ancak yönlendirme sırasında istek yöntemi GET’e dönmüş veya aynı POST gövdesi yeni adrese yeniden gönderilmiş olabilir. Son durum kodunu görmek, aradaki isteğin anlamını açıklamaz. Araç testine yönlendirme zincirindeki yöntem ve gövde kaydını da dahil etmek gerekir.

Bu makaledeki deneme yalnız yerel, sentetik bir yankı hizmetini anlatır. qty=2 gövdesi bir satın alma, rezervasyon veya gerçek iş oluşturmaz. Hedef hizmet yalnız aldığı yöntemi ve gövdeyi kaydeder. Böylece yönlendirme davranışı yan etkili bir sistemi kullanmadan gözlenebilir. Kaynaklardaki HTTP kuralları ile aşağıdaki küçük deneme sözleşmesini ayrı tutuyoruz; bir kodun varlığı belirli bir kurum aracının nasıl çalıştığını tek başına kanıtlamaz.

303 ve 307 aynı aktarım değildir

RFC 9110, 303 yanıtını başka bir kaynaktan GET veya HEAD ile temsil edinmeye yönlendirme olarak tanımlar. 307 otomatik yönlendirmesinde ise istemci istek yöntemini değiştirmemelidir. Buradaki ilk istek POST olduğundan 303 izinde GET, 307 izinde POST bekleriz. Yönlendirmeyi otomatik izleyip izlememe ve gövdenin yeniden gönderilebilirliği ayrıca istemci davranışına bağlıdır; bunları test kaydında belirtin.Kaynak: IETF — RFC 9110, 303 ve 307

İki senaryo bağımsız başlar; birinin yanıtı diğerine giriş yapılmaz. Her ilk isteğin kimliği ayrı olabilir, fakat sentetik gövde aynıdır. Bu sayede sonuç farkını gövde değişikliğine değil, yönlendirme davranışına bağlayabilirsiniz. Gövdeyi bir akış olarak yalnız bir kez okunabilir biçimde gönderen istemcide yeniden gönderim farklı sınırlara takılabilir. Bu örnekte küçük ve yeniden okunabilir sabit metin gövdesi varsayılmıştır.

Hedefte neyin geldiğini kaydedin

303: İstemci yönlendirilen kaynağı okumak için GET yaptı; eski POST gövdesi hedefte yok.
307: İstemci yöntemi korudu; yeniden gönderilebilir aynı gövde hedefe gitti.
İki son yanıt da 200 olabilir. Bu sayı tek başına aradaki yöntemi göstermez.

303 sonrası elde edilen sayfa önceki işlemin sonucu hakkında bilgi taşıyabilir; fakat hedef GET isteği ilk POST’un aynısı değildir. 307 ise yöntemi korusa bile yeni hedefin gerçekten aynı iş sözleşmesini uyguladığına kanıt değildir. Bu nedenle ajan “200 aldım” demek yerine beklenen kaynak kimliği, yanıt şeması ve işlem durumu gibi görev koşullarını da kontrol etmelidir. HTTP aktarımı ile işin tamamlanması ayrı katmanlardır.

Bu izdeki gövde kaydı yalnız sentetik qty=2 verisi içindir. Gerçek bir test sisteminde gövdenin tamamını uygulama günlüğüne yazmak gerekli olmayabilir; beklenen alanların güvenli özeti veya karşılaştırma özeti kullanılabilir. Burada hedefin ne aldığını görmek öğrenme amacına hizmet eder. Üretim günlüklerinin kapsamı ise o sistemin veri ve hata inceleme ihtiyaçlarına göre ayrıca belirlenir.

Yeni adresin işlem yetkisini de inceleyin

Bir yönlendirme, kullanıcının başka bir hedefe veri gönderme yetkisini kendiliğinden genişletmez. Araç entegrasyonunun izinli hedefleri varsa yeni adres her geçişte bunlarla karşılaştırılır. Özellikle yöntem ve gövde korunan bir yönlendirmede, istek içeriğinin hangi hizmete gideceği önemlidir. Bizim denememizde iki hedef aynı yerel hizmetteki /echo yoludur; harici adrese veya gerçek hesaba istek yapılmaz.

Ayrıca yönlendirme döngüsünü tamamlanmış iş gibi saymayın. /a ve /b birbirine yönlendiriyorsa son hedef hiç oluşmayabilir. İstemcinin azami yönlendirme sayısı ve toplam süre sınırı bu durumda devreye girer. Süre dolduğunda ilk işin hiç gerçekleşmediği sonucu da otomatik çıkmaz. Yan etkili gerçek araçlarda durum sorgusu ve tekrar politikası kendi sözleşmesine göre ele alınır.

Son yanıttan önce zinciri isteyen istem

İki bağımsız yerel yankı testi var. İlk istek POST, sabit gövde qty=2. Bir yol 303, diğeri 307 ve Location=/echo döndürüyor. İstemci otomatik yönlendirme izliyor; hedef yalnız yöntem/gövdeyi yanıtlıyor. Her senaryoda ilk istek, yönlendirme ve hedef isteğini ayrı yaz. 303 sonrası GET ile 307 sonrası POST farkını açıkla. Son 200’ü gerçek işlem başarısı sayma. İzinli yerel hedef dışına istek önerme ve gövdeyi kendiliğinden yeniden başlatma.

Testi çalıştırırken yönlendirme kapalı kip de yararlıdır. Bu kipte istemci ilk 303 veya 307 yanıtını ve Location alanını görür; ikinci isteği yapmaz. Böylece sunucunun gönderdiği yönlendirmeyle istemcinin onu nasıl izlediğini ayrı inceleyebilirsiniz. Kayıtta hangi kipin kullanıldığı bulunmalıdır. İkinci isteğin hiç yapılmadığı bir çalıştırmada hedef gövdesi hakkında gözlenmiş sonuç yazmayın.

• Yönlendirme kodu ve Location kaydedildi mi?
• İstemcinin otomatik izleme kipi açık mı?
• Hedef yöntemi ve gövde varlığı beklentiye uyuyor mu?
• Son kaynak ve iş durumu ayrı doğrulandı mı?

Otomatik izlemeyi kapatınca ne kalır?

Aynı POST ve 307 senaryosunda istemci yönlendirmeyi otomatik izlemiyor olsun. Kaç HTTP isteği yapılır, hangi yanıt gözlenir ve /echo için yöntem/gövde kaydı var mıdır? Sonra 303 senaryosunu otomatik izleyen ilk denemeye dönün: hedefe qty=2 parametresini kendiliğinden URL sorgusu olarak eklemek verilen sözleşmenin parçası mıdır? İki durumu ayrı açıklayın.

Otomatik izleme kapalıysa bir POST yapılır, 307 ve Location alınır; /echo çağrısı olmadığı için hedef gövdesi gözlemi yoktur. 303 sonrasında eski gövdeyi URL sorgusuna taşımak bu sözleşmede tanımlı değildir; kendiliğinden eklenmez. İlk otomatik 303 izinde hedef GET gövdesizdir.

Araç kabul kaydına yalnız son URL ve durum kodunu koymak yerine yönlendirme sayısı, yöntem değişimi ve hedef koşulunu da ekleyin. Böylece AI ajanının hangi isteği gerçekten yaptığını anlayabilir, aktarımın başarısını işin başarısı yerine kullanmasını önleyebilirsiniz.