هل من الآمن إعادة التوجيه إلى نفس عنوان URL؟

Question

لدي عناوين URL للنموذج http://domain/image/⟨uuid⟩/42x42/some_name.png.تم تكوين خادم الويب (nginx) للبحث عن ملف /some/path/image/⟨uuid⟩/thumbnail_42x42.png, وإذا لم يكن موجودًا، فإنه يرسل عنوان URL إلى الواجهة الخلفية (Django عبر mod_wsgi) والذي يقوم بعد ذلك بإنشاء الصورة المصغرة.ثم تقوم الواجهة الخلفية بإصدار إعادة توجيه 302 إلى نفس عنوان URL الذي طلبه العميل، مع فكرة أنه عند هذا الطلب الثاني، سيلاحظ الخادم الملف المصغر ويرسله مباشرة.

السؤال هو هل سيعمل هذا مع جميع المتصفحات؟لم يُظهر الاختبار أي مشاكل حتى الآن، ولكن هل يمكنني التأكد من أن جميع وكلاء المستخدم سوف يفسرون ذلك على النحو المنشود؟

تحديث: اسمحوا لي أن أوضح القصد.حاليا يعمل هذا على النحو التالي:

1. يطلب العميل صورة مصغرة للصورة.
2. يرى الخادم أن الملف غير موجود، لذلك يقوم بإعادة توجيه الطلب إلى الواجهة الخلفية.
3. تقوم الواجهة الخلفية بإنشاء الصورة المصغرة وإرجاع 302.
4. تقوم الواجهة الخلفية بتحرير جميع الموارد، مما يسمح للخادم بمشاركة الملف الذي تم إنشاؤه حديثًا مع العملاء الحاليين واللاحقين.

إن جعل الواجهة الخلفية تخدم الصورة التي تم إنشاؤها حديثًا هو أمر أسوأ لسببين:

1. ويجب إنشاء طريقتين لخدمة نفس البيانات؛
2. الخادم أفضل بكثير في تقديم المحتوى الثابت.ماذا لو كان لدى العميل رابط بطيء للغاية؟الواجهة الخلفية ليست سريعة ولا ذات كفاءة في الذاكرة بشكل خاص، كما أن الاحتفاظ بها في الذاكرة أثناء تغذية العميل بالملعقة يمكن أن يكون مضيعة للوقت.

لذلك أحافظ على عمل الواجهة الخلفية لأقل قدر ممكن من الوقت.

التحديث²: سأكون ممتنًا حقًا لبعض مراجع RFC أو آراء شخص لديه خبرة في الكثير من المتصفحات.كل هذه الإجابات الإيجابية ممتعة لكنها تبدو لا أساس لها إلى حد ما.

Answer 1

إذا لم يحدث ذلك، العميل مكسور.سيتبع معظم العملاء حلقات إعادة التوجيه حتى تصل إلى الحد الأقصى للقيمة.لذا، نعم، يجب أن يكون الأمر جيدًا حتى لا تقوم الواجهة الخلفية لديك بإنشاء الصورة المصغرة لأي سبب من الأسباب.

يمكنك بدلاً من ذلك تغيير عناوين URL لتكون http://domain/djangoapp/generate_thumbnail وسيؤدي ذلك إلى إرجاع الصورة المصغرة ونوع المحتوى المناسب وما إلى ذلك

Answer 2

نعم، من الجيد إعادة التوجيه إلى نفس URI الذي كنت تستخدمه سابقًا.