هل من الممكن تخزين طرق POST مؤقتًا في HTTP؟
https://stackoverflow.com/questions/626057
-
05-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
مع دلالات التخزين المؤقت البسيطة جدًا:إذا كانت المعلمات هي نفسها (وعنوان URL هو نفسه بالطبع)، فهي نتيجة ناجحة.هل هذا ممكن؟مُستَحسَن؟
المحلول
المناظرة آر إف سي 2616 في القسم 9.5 (POST) يسمح بالتخزين المؤقت لملف إجابة إلى رسالة POST، إذا كنت تستخدم الرؤوس المناسبة.
الردود على هذه الطريقة ليست قابلة للتخطيط ، ما لم تتضمن الاستجابة مراقبة ذاكرة التخزين المؤقت المناسبة أو تنتهي صلاحية حقول الرأس.ومع ذلك ، يمكن استخدام استجابة 303 (انظر الأخرى) لتوجيه وكيل المستخدم لاسترداد مورد مخبأ.
لاحظ أن نفس RFC ينص بشكل صريح في القسم 13 (التخزين المؤقت في HTTP) على أن ذاكرة التخزين المؤقت يجب أن تبطل الكيان المقابل بعد POST طلب.
يجب أن تتسبب بعض أساليب HTTP في إبطال كيان.هذا هو إما الكيان المشار إليه من قبل request-uri ، أو عن طريق رؤوس الموقع أو محتوى الموقع (إذا كان موجودًا).هذه الطرق هي:
- PUT - DELETE - POST
ليس من الواضح بالنسبة لي كيف يمكن لهذه المواصفات أن تسمح بالتخزين المؤقت ذي المعنى.
نصائح أخرى
ووفقا لRFC 2616 القسم 9.5:
<اقتباس فقرة>و"الردود على أسلوب POST ليست القابلة للتخزين المؤقت، ما لم الاستجابة يشمل المناسب ذاكرة التخزين المؤقت-التحكم أو ينتهي حقول رأس ".
وهكذا، نعم، يمكنك تخزين ما بعد استجابة الطلب، ولكن فقط إذا وصل مع رؤوس المناسبة. في معظم الحالات التي لا تريد إلى ذاكرة التخزين المؤقت استجابة. ولكن في بعض الحالات - مثل إذا كنت لا حفظ أية بيانات على الخادم - انه من المناسب تماما.
ملحوظة، ولكن العديد من المتصفحات، بما في فايرفوكس الحالي 3.0.10، وليس مؤقتا استجابة وظيفة بغض النظر عن رؤوس. IE يتصرف بذكاء أكثر في هذا الصدد.
والآن، أريد لتوضيح بعض الالتباس هنا فيما يتعلق RFC 2616 S. 13.10. أسلوب POST على URI "لا يفسد الموارد للتخزين المؤقت" وبعض ذكرنا هنا. فإنه يجعل النسخة المخبأة في السابق من أن URI التي لا معنى لها، حتى لو أشارت رؤوس تحكم ذاكرة التخزين المؤقت نضارة مدة أطول.
إجمالي:
أساسًا POST ليست عملية عاجزة.لذلك لا يمكنك استخدامه للتخزين المؤقت.يجب أن تكون عملية GET غير فعالة، لذا يتم استخدامها بشكل شائع للتخزين المؤقت.
يرجى الاطلاع على القسم 9.1 من HTTP 1.1 RFC 2616 س.9.1.
بخلاف دلالات طريقة GET:
تهدف طريقة POST نفسها لغويًا إلى نشر شيء ما على أحد الموارد.لا يمكن تخزين POST مؤقتًا لأنه إذا قمت بشيء ما مرة واحدة مقابل مرتين مقابل ثلاث مرات، فأنت تقوم بتغيير مورد الخادم في كل مرة.كل طلب مهم ويجب تسليمه إلى الخادم.
تهدف طريقة PUT نفسها لغويًا إلى وضع أو إنشاء مورد.إنها عملية غير فعالة، لكن لن يتم استخدامها للتخزين المؤقت لأنه من الممكن حدوث عملية حذف في هذه الأثناء.
إن أسلوب DELETE نفسه يهدف إلى حذف أحد الموارد بشكل دلالي.إنها عملية غير فعالة، ولكن لن يتم استخدامها للتخزين المؤقت لأنه من الممكن أن يحدث PUT في هذه الأثناء.
فيما يتعلق بالتخزين المؤقت من جانب العميل:
سيقوم متصفح الويب دائمًا بإعادة توجيه طلبك حتى لو كان لديه استجابة من عملية POST سابقة.على سبيل المثال، يمكنك إرسال رسائل بريد إلكتروني باستخدام Gmail بفاصل يومين.قد يكونا نفس الموضوع والنص، ولكن يجب إرسال كلتا الرسالتين عبر البريد الإلكتروني.
فيما يتعلق بالتخزين المؤقت للوكيل:
لن يقوم خادم HTTP الوكيل الذي يعيد توجيه رسالتك إلى الخادم بتخزين أي شيء سوى طلب GET أو HEAD.
فيما يتعلق بالتخزين المؤقت للخادم:
لن يتعامل الخادم تلقائيًا مع طلب POST من خلال التحقق من ذاكرة التخزين المؤقت الخاصة به.ولكن بالطبع يمكن إرسال طلب POST إلى التطبيق الخاص بك أو الوظيفة الإضافية ويمكنك الحصول على ذاكرة التخزين المؤقت الخاصة بك والتي تقرأ منها عندما تكون المعلمات هي نفسها.
إبطال مورد:
فحص HTTP 1.1 RFC 2616 س.13.10 يوضح أن طريقة POST يجب أن تبطل صلاحية المورد للتخزين المؤقت.
إذا كنت لا مخبأ استجابة وظيفة، يجب أن يكون في اتجاه تطبيق ويب. هذا ما هو المقصود ب "ردود على هذه الطريقة ليست cachable، ما لم تتضمن ردا مناسبا ذاكرة التخزين المؤقت-التحكم أو منتهية حقول رأس".
ويمكن للمرء أن الافتراض بأن التطبيق، الذي لا يعرف ما إذا كان أو لم يكن نتائج الوظائف هي idempotent، يقرر ما إذا كان أو لا نعلق على رؤوس اللازمة والمناسبة تحكم ذاكرة التخزين المؤقت. إذا الرؤوس التي تشير إلى التخزين المؤقت يسمح موجودة، وتطبيق أقول لك أن المنصب هو، في الواقع، سوبر-GET. أن استخدام وظيفة كان مطلوبا فقط بسبب كمية البيانات غير ضرورية وغير ذات صلة (لاستخدام URI كمفتاح التخزين المؤقت) الضروري لتنفيذ العملية idempotent.
وبعد GET يمكن أن تتحقق من ذاكرة التخزين المؤقت في ظل هذا الافتراض.
وأحد التطبيقات التي فشل إرفاق رؤوس اللازمة والصحيحة للتمييز بين cachable وغير cachable الردود آخر هو على خطأ لأية نتائج التخزين المؤقت غير صالحة.
وقال ان كل وظيفة أن يضرب مخبأ يتطلب التحقق من صحة استخدام رؤوس المشروطة. هذا مطلوب من أجل تحديث محتويات ذاكرة التخزين المؤقت لتجنب نتائج ما بعد لا تنعكس في الردود على طلبات حتى بعد انتهاء مدة الكائن.
إذا كان شيئا لا في الواقع تغيير البيانات على موقع الويب الخاص بك، يجب أن يكون طلب GET. حتى لو كان نموذج، لا يزال بإمكانك تعيينه طلب الحصول عليها. في حين، مثل آخرين يشيرون إلى، هل يمكن تخزين نتائج ما بعد، فإنه لا معنى الدلالي لأن وظيفة من حيث التعريف هو تغيير البيانات.
لقد حللت كافة نوتنغهام عندما يكون ذلك ممكنا لذاكرة التخزين المؤقت استجابة لPOST. لاحظ أن طلبات اللاحقة التي ترغب في الاستفادة من التخزين المؤقت يجب أن يكون GET أو طلبات الرأس. انظر أيضا httpbis
<اقتباس فقرة>والمشاركات لا تتعامل في تمثيل الدولة التي تم تحديدها، 99 مرات من أصل 100. ومع ذلك، هناك حالة واحدة حيث يفعل. عندما خادم يخرج من طريقها إلى القول بأن هذا الرد المنصب هو تمثيل لURI لها، من خلال تحديد رأس Content-الموقع وهذا هو نفس الطلب URI. وعندما يحدث ذلك، واستجابة المنصب هو تماما مثل استجابة GET إلى نفس URI. يمكن أن يكون مؤقتا وإعادة استخدامها - ولكن فقط من أجل المستقبل طلبات GET.
وبالطبع فمن الممكن. إذا كنت ترغب في التقاط طلبات POST إرسالها إلى الخادم الخاص بك، وتخزين البيانات اعادتهم إلى إعادة بعث في وقت لاحق - لا عرق
والجزء صعبة يأتي في بشأن "الدولة". كيف يمكنك أن تقرر البيانات التي تريد إرسالها إلى المستخدم حقا يجب أن تكون هي نفسها؟ ماذا لو الكوكيز له قد تغيرت - هل هذا تغيير البيانات التي تريد أن يرسل إلى الخلف
وماذا عن إذا قام بها المستخدم طلب POST إلى صفحتك الرئيسية، ومنذ المرة الأخيرة التي فعلت ذلك، مستخدم آخر أرسلت له رسالة (باستخدام بعض النظام داخل موقع الويب الخاص بك.) سيكون لديك لتحديد أنه نتيجة لchange- من الدولة، وإرسال النسخة الجديدة من صفحتك الرئيسية، مع إخطار حول رسالة للمستخدم في المرة القادمة انه يقوم بتحميل الصفحة الرئيسية. حتى لو المعلمات وظيفة هي نفسها.
ومع فايرفوكس 27.0 ومع httpfox، في 19 مايو 2014، ورأيت سطر واحد من هذا: 00: 03: 58.777 0.488 657 (393) وظيفة (الكاش) نص / HTML https://users.jackiszhp.info/ S4UP
ومن الواضح أن مؤقتا استجابة طريقة آخر، وأنه هو أيضا في HTTPS. لا يصدق!
ويستخدم POST في جليل اياكس. إعادة استجابة مؤقتا لشغل وظيفة الهزائم قناة اتصال والآثار الجانبية لتلقي الرسالة. هذا هو في غاية السوء. كما انها الألم الحقيقي لتعقب. ينصح بشدة ضد.
وهناك مثال تافهة ستكون الرسالة التي، كأثر جانبي، يدفع راتبك 10000 $ خلال الأسبوع الحالي. كنت لا ترغب في الحصول على "OK، التي مرت بها!" ظهر الصفحة التي تم تخزينها مؤقتا الاسبوع الماضي. والأكثر تعقيدا الحالات في العالم الحقيقي أخرى تؤدي إلى مرح مماثل.
