আইআইএস 7 200 এর পরিবর্তে 304 প্রদান করে

10

আইআইএস I এর সাথে আমার একটি অদ্ভুত সমস্যা রয়েছে
Sometimes কখনও কখনও এটি 200 এর পরিবর্তে 304 ফেরত বলে মনে হয়।

এখানে ফিডলারের সাথে ধরা পড়ার জন্য একটি নমুনা অনুরোধ রইল:
(নোট করুন যে অনুরোধ করা ফাইলটি এখনও আমার ব্রাউজারগুলির ক্যাশে নেই)

GET https://[mysite]/Content/js/jquery.form.js HTTP/1.1
Accept: */*
Referer: https://[mysite]/Welcome/News
Accept-Language: sv-SE
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; OfficeLiveConnector.1.4; OfficeLivePatch.1.3; .NET4.0C; .NET4.0E)
Accept-Encoding: gzip, deflate
Host: [mysite]
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: ...

নোট করুন যে অনুরোধটিতে কোনও-যদি-সংশোধিত-তত বা কোনও-না-মিল নেই।
তবে এখনও প্রতিক্রিয়াটি হ'ল:

HTTP/1.1 304 Not Modified
Cache-Control: public
Expires: Tue, 02 Mar 2010 06:26:08 GMT
Last-Modified: Mon, 22 Feb 2010 21:58:44 GMT
ETag: "1CAB40A337D4200"
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Mon, 01 Mar 2010 17:06:34 GMT

এখানে কি ভুল হতে পারে তার কারও কি কোনও ধারণা আছে?

আমি উইন্ডোজ ওয়েব সার্ভার 2008 আর 2 এ আইআইএস 7 চালাচ্ছি।

সম্পাদনা করুন:

আমি একটি কার্যবিবরণী পেয়েছি, ক্যাচিং সক্ষম করুন এবং তারপরে এটি এক্সটেনশান স্তরে অক্ষম করে দিয়েছিলাম আমার জন্য কৌশলটি।

<configuration>
  <system.webServer>
    <caching enabled="true" enableKernelCache="true">
      <profiles>
        <add extension=".png" policy="DisableCache" kernelCachePolicy="DisableCache" />
        <add extension=".gif" policy="DisableCache" kernelCachePolicy="DisableCache" />
        <add extension=".js" policy="DisableCache" kernelCachePolicy="DisableCache" />
        <add extension=".css" policy="DisableCache" kernelCachePolicy="DisableCache" />
      </profiles>
    </caching>
    <staticContent>
      <clientCache cacheControlMode="NoControl" />
    </staticContent>
  </system.webServer>
</configuration>

windows-server-2008 iis-7 asp.net

— ওলা হার্ডাহল
সূত্র

আমার ঠিক একই সমস্যা রয়েছে এবং এটি একটি খুব ব্যস্ত ওয়েব সার্ভারে প্রচুর সমস্যা সৃষ্টি করছে। আইআইএস একটি 304 প্রদান করে, যদিও ক্লায়েন্টের কাছে এখনও সংস্থানটির কোনও অনুলিপি নেই।

— ফিলিপ লেবার্ট

@ ফিলিপ, আপনি কি এখনও কোনও সমাধান খুঁজে পেয়েছেন? অন্যথায় উপরের একপাশে আমার সম্পাদনা দেখুন এবং নীচের নতুন উত্তরটি চেকআউট করুন।

— ওলা হার্ডাহাল

@ ওলা হার্ডাহল, আপনার কাজটি নিখুঁত: :) আমারও ঠিক এই সমস্যাটি ছিল। ধন্যবাদ!

— আরডি আরম

3

HTTP1.1 স্পেসের 14.9 ধারা অনুসারে , no-cacheক্যাশে-নিয়ন্ত্রণ শিরোলেখের জন্য নির্দেশটি কেবলমাত্র উত্স সার্ভার দ্বারা অপ্রয়োগযোগ্য , যার অর্থ আইআইএস আপনার অনুরোধে শিরোনামটিকে উপেক্ষা করছে।

ক্যাশে-নিয়ন্ত্রণ নির্দেশাবলী এই সাধারণ বিভাগগুলিতে বিভক্ত করা যেতে পারে:
  - Restrictions on what are cacheable; these may only be imposed
উত্স সার্ভার দ্বারা।

বিভাগ 14.9.1 সংজ্ঞায়িত করেছে public, privateএবং no-cacheযা ক্যাশেযোগ্য তা সীমাবদ্ধ হিসাবে নির্দেশক হিসাবে, যা কেবল সার্ভার দ্বারা চাপানো যেতে পারে।

আপনি যদি নিজের .js ফাইলটি ক্যাশে করে না রাখতে চান তবে আপনাকে no-cacheঅ্যাপে নির্দেশিকা নির্ধারণ করতে হবে (যেমন- এএসপি.এনইটি কোড) অথবা আপনাকে নির্দেশটি Cache-Controlব্যবহারের জন্য অনুরোধে হেডারটি পরিবর্তন করতে হবে no-storeপরিবর্তে no-cache।

সম্পাদনা:
আপনার মন্তব্যের ভিত্তিতে - হ্যাঁ আমি ধরে নিয়েছি আপনি ফাইল ক্যাশে করতে চান নি। 304, তারপরে, ফাইলটি আইআইএসের অভ্যন্তরীণ ক্যাশেগুলির মধ্যে একটিতে থাকার ফলে আসতে পারে coming এগুলি একবার দেখুন:

— squillman
সূত্র

আমার মনে হয় আপনি আমার সমস্যাটি এখানে ভুল বুঝেছেন। ফাইলটি এখনও আমার ক্যাশে নেই। তবে এখনও সার্ভার একটি 304 দিয়ে উত্তর দেয় ... সমস্ত বড় ব্রাউজারে সাইটটি ব্রাউজ করার সময় এলোমেলোভাবে ঘটেছিল বলে মনে হয়।

— ওলা হার্ডাহাল

@ ওলা হার্ডাহাল: আমার সম্পাদনাটি একবার দেখুন।

— স্কুইলম্যান

আমি

— আইআইএসেও

1

আমি কিছুক্ষণ ধরে একই সমস্যা হয়ে এসেছি এবং সমস্ত ক্যাচিং বন্ধ করে দিয়েছি ... তবে আমি আইআইএস for এর জন্য সংক্ষেপণ মডিউলটি ইনস্টল করেছি যা ডিফল্টরূপে আমার বিদ্যমান সাইটগুলিতে স্থির ফাইলগুলির সংক্ষেপণ সক্ষম করেছিল। আমি প্রভাবিত সাইটের জন্য সমস্ত সংক্ষেপণ বন্ধ করে দিয়েছি এবং এখন তারা সূক্ষ্ম স্পর্শ কাঠের কাজ করছে বলে মনে হচ্ছে ।

1

আমরা এই বাগটিটিও অনুভব করছিলাম তবে আমরা একটি সম্পদ পরিচালনার লাইব্রেরি (ক্যাসেট) ব্যবহার করছিলাম। এই ইস্যুটির বিস্তৃত তদন্তের পরে, আমরা দেখতে পেয়েছি যে এএসপি.এনইটি, আইআইএস এবং ক্যাসেটের সংমিশ্রণে এই সমস্যার মূল কারণ। আমি নিশ্চিত নই যে এটি আপনার সমস্যা ( Headersএপিআইয়ের পরিবর্তে এপিআই ব্যবহার করা Cache) তবে প্যাটার্নটি একই রকম বলে মনে হচ্ছে।

বাগ # 1

ক্যাসেটটি Vary: Accept-Encodingএকটি বান্ডিলের প্রতিক্রিয়ার অংশ হিসাবে শিরোনাম সেট করে যেহেতু এটি gzip / deflate সহ সামগ্রীটিকে এনকোড করতে পারে:

বান্ডেলআরকুয়েস্টহ্যান্ডলার: https://github.com/andrewdavey/cassette/blob/a2d9870eb0dc3585ef3dd542287595bc6162a21a/src/Cassette.Aspnet/BundleRequestHandler.cs#L78
HttpResponseUtil: https://github.com/andrewdavey/cassette/blob/a2d9870eb0dc3585ef3dd542287595bc6162a21a/src/Cassette.Aspnet/HttpResponseUtil.cs#L45

তবে, এএসপি.নেট আউটপুট ক্যাশে সর্বদা ক্যাশে হওয়া প্রতিক্রিয়াটি সর্বদা ফিরিয়ে দেবে। উদাহরণস্বরূপ, যদি প্রথম অনুরোধ আছে Accept-Encoding: gzipএবং ক্যাসেট gzipped বিষয়বস্তু ফেরৎ, ASP.NET আউটপুট ক্যাশ হিসাবে URL টি ক্যাশে করবে Content-Encoding: gzip। একই ইউআরএলের পরবর্তী অনুরোধ কিন্তু ভিন্ন গ্রহণযোগ্য এনকোডিং সহ (যেমন Accept-Encoding: deflate) এর সাথে ক্যাশে দেওয়া প্রতিক্রিয়া ফিরে আসবে Content-Encoding: gzip।

এই বাগ ব্যবহার ক্যাসেট দ্বারা ঘটিত হয় HttpResponseBase.Cacheআউটপুট ক্যাশে সেটিংস (যেমন সেট করতে এপিআই Cache-Control: public) কিন্তু ব্যবহার HttpResponseBase.Headersসেট করতে এপিআই Vary: Accept-Encodingহেডার। সমস্যা হল ASP.NET হয় OutputCacheModuleহয় না প্রতিক্রিয়া হেডার সচেতন; এটি কেবলমাত্র CacheAPI এর মাধ্যমে কাজ করে । এটি, এটি প্রত্যাশা করে যে বিকাশকারী কেবলমাত্র স্ট্যান্ডার্ড এইচটিটিপি-র পরিবর্তে অদৃশ্যভাবে দৃ tight়-জোড়াযুক্ত API ব্যবহার করবে।

বাগ # 2

আইআইএস 7.5 (উইন্ডোজ সার্ভার 2008 আর 2) ব্যবহার করার সময়, বাগ # 1 আইআইএস কার্নেল এবং ব্যবহারকারীর ক্যাশে পৃথক সমস্যা সৃষ্টি করতে পারে। উদাহরণস্বরূপ, একবার একটি বান্ডিল সফলভাবে ক্যাশে হয়ে গেলে Content-Encoding: gzip, এটি দিয়ে আইআইএস কার্নেল ক্যাশে এটি দেখা সম্ভব netsh http show cachestate। এটি 200 স্থিতি কোড এবং "জিজিপ" এর সামগ্রী এনকোডিং সহ একটি প্রতিক্রিয়া দেখায়। যদি পরবর্তী অনুরোধটির আলাদা গ্রহণযোগ্য এনকোডিং থাকে (উদাহরণস্বরূপ Accept-Encoding: deflate) এবংIf-None-Match বান্ডেলের হ্যাশের সাথে মিলে এমন একটি শিরোলেখ থাকে, তবে আইআইএসের কার্নেল এবং ব্যবহারকারী মোড ক্যাশে অনুরোধটি মিস হিসাবে বিবেচিত হবে । সুতরাং, অনুরোধ ক্যাসেট দ্বারা পরিচালিত হতে পারে যা 304 ফেরত দেয়:

বান্ডেলআরকিউস্টহ্যান্ডলার: https://github.com/andrewdavey/cassette/blob/a2d9870eb0dc3585ef3dd542287595bc6162a21a/src/Cassette.Aspnet/BundleRequestHandler.cs#L44

তবে, একবার আইআইএসের কার্নেল এবং ব্যবহারকারী মোডগুলি প্রতিক্রিয়াটি প্রক্রিয়া করার পরে, তারা দেখতে পাবে যে ইউআরএলটির প্রতিক্রিয়া বদলেছে এবং ক্যাশে আপডেট করা উচিত। যদি আইআইএস কার্নেল ক্যাশেটি netsh http show cachestateআবার পরীক্ষা করা হয় তবে ক্যাশেড 200 প্রতিক্রিয়া 304 টি প্রতিক্রিয়া দ্বারা প্রতিস্থাপিত হবে। বান্ডলে পরবর্তী সমস্ত অনুরোধগুলি নির্বিশেষে Accept-Encodingএবং If-None-Match304 টি প্রতিক্রিয়া ফিরিয়ে দেবে। আমরা এই বাগের ধ্বংসাত্মক প্রভাবগুলি দেখেছি যেখানে সমস্ত ব্যবহারকারীদের আমাদের মূল স্ক্রিপ্টের জন্য একটি এলোমেলো অনুরোধের কারণে একটি অপ্রত্যাশিত Accept-Encodingএবং এর জন্য 304 সরবরাহ করা হয়েছিল If-None-Match।

সমস্যাটি মনে হচ্ছে যে আইআইএস কার্নেল এবং ব্যবহারকারী মোড ক্যাশেগুলি Accept-Encodingশিরোনামের ভিত্তিতে পরিবর্তিত হতে পারে না । এর প্রমাণ হিসাবে, Cacheনীচের কাজের সাথে API ব্যবহার করে , আইআইএস কার্নেল এবং ব্যবহারকারী মোড ক্যাশে সর্বদা এড়ানো যায় বলে মনে হয় (কেবলমাত্র ASP.NET আউটপুট ক্যাশে ব্যবহৃত হয়)। এটি netsh http show cachestateনীচের কাজের সাথে খালি কিনা তা পরীক্ষা করে নিশ্চিত হওয়া যায়। এএসপি.এনইটি আইআইএস কর্মীর সাথে সরাসরি প্রতি অনুরোধে আইআইএস কার্নেল এবং ব্যবহারকারী মোড ক্যাশে সক্ষম বা অক্ষম করতে যোগাযোগ করে।

আমরা এই বাগটি আইআইএসের নতুন সংস্করণগুলিতে পুনরায় উত্পাদন করতে পারিনি (যেমন আইআইএস এক্সপ্রেস 10)। তবে, বাগ # 1 এখনও পুনরুত্পাদনযোগ্য ছিল।

এই বাগের জন্য আমাদের আসল ফিক্সটি কেবলমাত্র অন্যের মতো উল্লিখিত ক্যাসেট অনুরোধের জন্য আইআইএস কার্নেল / ব্যবহারকারী মোড ক্যাশেিং অক্ষম করা ছিল। এটি করে, আমরা আমাদের ওয়েব সার্ভারের সামনে ক্যাশিংয়ের একটি অতিরিক্ত স্তর স্থাপন করার সময় বাগ # 1টি অনাবৃত করেছিলাম। কোয়েরি স্ট্রিং হ্যাকটি যে কারণে কাজ করেছে তা হ'ল কারণ, OutputCacheModuleযদি CacheAPI এর উপর ভিত্তি করে পরিবর্তিত হওয়ার জন্য API ব্যবহার করা না হয় QueryString এবং অনুরোধটির একটি থাকে তবে একটি ক্যাশে মিস রেকর্ড করবেQueryString ।

কার্যসংক্রান্ত

আমরা যাইহোক ক্যাসেট থেকে সরে যাওয়ার পরিকল্পনা করে চলেছি, সুতরাং আমাদের নিজস্ব ক্যাসেটের কাঁটাচামড়া (বা পিআর মার্জ করার চেষ্টা করা) রক্ষা না করে আমরা এই ইস্যুটি সম্পর্কে কাজ করার জন্য এইচটিটিপি মডিউলটি ব্যবহার করার বিকল্প বেছে নিয়েছি।

public class FixCassetteContentEncodingOutputCacheBugModule : IHttpModule
{
    public void Init(HttpApplication context)
    {
        context.PostRequestHandlerExecute += Context_PostRequestHandlerExecute;
    }

    private void Context_PostRequestHandlerExecute(object sender, EventArgs e)
    {
        var httpContext = HttpContext.Current;

        if (httpContext == null)
        {
            return;
        }

        var request = httpContext.Request;
        var response = httpContext.Response;

        if (request.HttpMethod != "GET")
        {
            return;
        }

        var path = request.Path;

        if (!path.StartsWith("/cassette.axd", StringComparison.InvariantCultureIgnoreCase))
        {
            return;
        }

        if (response.Headers["Vary"] == "Accept-Encoding")
        {
            httpContext.Response.Cache.VaryByHeaders.SetHeaders(new[] { "Accept-Encoding" });
        }
    }

    public void Dispose()
    {

    }
}

আমি আশা করি এটি কাউকে সাহায্য করবে 😄!

— TheCloudlessSky
সূত্র