نظرات مطالب
شروع به کار با EF Core 1.0 - قسمت 7 - بررسی رابطه‌ی One-to-Many
«بهبود عملکرد» با «بهبود کارآیی» یکی نیست. پیاده سازی سیستم change tracking در حالت کلی، بدون پیاده سازی مباحث AOP غیرممکن است. بهتر است دوره‌ی مرتبطی را در سایت در این مورد مرور کنید تا کلیات بحث تشکیل Proxyها بهتر مشخص شوند (و ... تشکیل پروکسی با روش‌های مختلفی و با الگوریتم‌های متفاوتی ممکن است و مهم نیست که dynamic proxy چندسکویی باشد یا خیر؛ این مورد نام یک الگوی طراحی شیء گرا است و نه یک کتابخانه‌ی خاص). هدف من از عنوان این مسایل، اشاره به کلیات زیرساخت پیاده سازی این مباحث هست.
برای نمونه زمانیکه مقدار خاصیت شیء واکشی شده‌ای از Context را تغییر می‌دهید و سپس SaveChanges را فراخوانی می‌کنید، در این بین یک پروکسی وجود دارد (یک لایه‌ی نامرئی و حائل بین شیء اصلی و تغییراتی که قرار است به آن اعمال شوند) که به تغییرات گوش فرا می‌دهد و در نهایت صرفا یک کوئری به روز رسانی آن فیلد خاص را تولید می‌کند و نه تمام فیلدهای دیگر را. این نوع مفاهیم کلی در اینجا مدنظر هستند. یک نمونه پیاده سازی کلی این مفهوم را در اینجا می‌توانید مشاهده کنید.
همچنین EF Core 2.1 به همراه بسته‌ی Microsoft.EntityFrameworkCore.Proxies است که پیاده سازی Lazy loading را میسر کرده‌است و از Castel.Core هم استفاده می‌کند (یا همان Castle DynamicProxy که در دوره «Aspect oriented programming» مورد بررسی قرار گرفته‌است).
نظرات مطالب
React 16x - قسمت 1 - معرفی و شروع به کار
با IE هم کار می‌کند؛ با این تنظیمات:

- ابتدا پوشه‌ی node_modules/.cache را حذف کنید (مهم!).
- سپس دو بسته‌ی «npm install react-app-polyfill core-js» را نصب کنید.
- چند سطر زیر را به ابتدای فایل index.js اضافه کنید:
import "react-app-polyfill/ie11";
import "react-app-polyfill/stable";

import 'core-js/features/array/find';
import 'core-js/features/array/includes';
import 'core-js/features/number/is-nan';
- فایل package.json را ویرایش کنید و مدخل IE را به دو قسمت اضافه کنید:
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all",
      "ie 10"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version",
      "ie 10"
    ]
  }

سپس برنامه را اجرا کنید:

 
نظرات مطالب
ارتقاء به ASP.NET Core 1.0 - قسمت 13 - معرفی View Components
- همانطور که در مقدمه‌ی بحث هم عنوان شد، مفهوم Child Actions از نگارش Core حذف شده‌است؛ چون مشکلات زیادی دارد (به این لیست، مشکلات async و همچنین آغاز یک چرخه‌ی جدید MVC را هم اضافه کنید که کارآیی مناسبی ندارد و یک سربار به شمار می‌رود).
- جایگزین آن ViewComponet است و از لحاظ دسترسی به منابع و سرویس‌ها محدودیتی ندارد. یک مثال
- هنوز هم اگر صرفا نیاز به رندر یک پارشال View را به صورت Ajax ایی دارید، روش زیر کار می‌کند:
جایی که می‌خواستید Html.RenderAction را قرار دهید، قطعه کد Ajax ایی زیر را فراخوانی کنید:
<div id="dynamicContentContainer"></div>
<script>   
    $.get('@Url.Action("GetData", "Home")', {id : 1}, function(content){
            $("#dynamicContentContainer").html(content);
        });
</script>
کار آن دریافت محتوای html ایی اکشن متد ذیل و افزودن آن به div مشخص شده‌است.
[HttpGet]
public IActionResult GetData(int id)
{
   return PartialView(id);
}
با این پارشال View فرضی:
@model int 
<span>Values from controler :</span> @Model
مطالب
Claim Based Identity
بنده در حال توسعه‌ی یک CMS هستم و این کار را برای یادگیری MVC انجام میدم. الان هم تقریبا رسیدم به اواخر کار و انشالله اگه کار تمام شد، نرم افزار را به صورت سورس باز منتشر می‌کنم. الان رسیدم به قسمت مدیریت کاربران. همانطور که می‌دانید ASP.NET در نسخه‌های جدید خودش بر خلاف نسخه‌های قدیمی که از SQL Membership استفاده می‌کرد الان از سیستم Identity بهره می‌برد، که انشالله در نوشتارهای بعدی به موضوع Identity به تفصیل خواهیم پرداخت. در حقیقت  سیستم Identity یک نوع Claim Based Identity هست. اما حالا ببینیم که این Claim چی هست؟ اما قبل از آن یک سری اصطلاحات را که به درک بهتر مفهوم کمک می‌کند، باید تعریف کنیم:

Relying Party (RP) = Application

Service Providers (SP) = Application 

RP  یا SP یک Application می‌باشد که از Claim استفاده می‌کند. واژه‌ی Relying Party بدین دلیل انتخاب شده که Application روی یک Issuer به منظور تامین اطلاعات در مورد یک Identity تکیه می‌کند.

Subject = User

Principal = User

واژه‌ی Subject یا Principal در حقیقت یک User می‌باشد. این واژه زمانی معنا پیدا می‌کند که شما به User به عنوان یک Subject برای کنترل دسترسی، شخصی سازی (Personalization) و ... بنگرید. در Net Framework. به جای Subject از Principal استفاده می‌شود.

Security Token Service (STC) = Issuer

از دید فنی، STC یک رابط درون یک Issuer می‌باشد که درخواست‌ها (Request) را تأیید و اقدام به ساخت Issues Security Token (توکن‌های مسائل امنیتی) می‌نماید. توکن‌های مسائل امنیتی شامل یک سری Claim می‌باشند.

Identity Provider (IDP) = Issuer 

تامین کننده Identity یک Issuer یا Token Issuer می‌باشد که وظیفه‌ی تعیین اعتبار (Validation) کاربر مانند نام کاربری، رمز عبور و ... را بر عهده دارد.


Active Client = Smart or rich Client

Passive Client = Browser 

یک Active Client می‌تواند از یک کتابخانه‌ی پیچیده مانند WCF به منظور پیاده سازی پروتکل‌هایی که بتوانند یک Security Token را درخواست و پاس دهند، استفاده نمایند. به منظور پشتیبانی از مرورگرهای مختلف، سناریوهای passive از پروتکل‌های ساده‌تری به منظور درخواست و پاس دادن یک Security Token که بر روی پروتکل Http تکیه دارد استفاده می‌کند (Http Post - Http Get).


و اما Claim چیست؟

در حقیقت Claim عبارتست از یک بیانیه یا شرح که یک Subject در مورد خودش یا Subject دیگری می‌سازد. این بیانیه می‌تواند در مورد یک نام، هویت، کلید، گروه، حق دسترسی و یا یک قابلیت باشد. Claim‌ها بوسیله یک Provider صادر و سپس بسته بندی (Package) شده و بوسیله‌ی یک Issuer صادر می‌شوند که این Issuer عموما با نام Security Token Service شناخته می‌شود. 

به منظور آشنایی با این مبحث میتوانید به اینجا و اینجا مراجعه نمایید.

این نوشتار مقدمه‌ای بود بر مباحث ASP.NET Identity. بنده در حال ترجمه‌ی سه فصل آخر کتاب Pro ASP.NET Mvc 5 Platform که اختصاص به مبحث Identity دارد هستم. فصل 13 تقریبا تمام شده و انشالله بزودی آن‌را منتشر میکنم.

نظرات مطالب
سفارشی سازی ASP.NET Core Identity - قسمت چهارم - User Claims
مفهومی در ASP.NET Core Identity وجود دارد به نام AutomaticAuthenticate و AutomaticChallenge که سبب می‌شوند کاربر با وارد کردن آدرس سایت، به صورت خودکار اعتبارسنجی شود (اگر پیشتر کوکی لاگین او وجود داشته باشد). این موارد برای فعالسازی به تنظیمات ذیل نیاز دارند:
در متد ConfigureServices:
services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme);
و همچنین در متد Configure:
app.UseAuthentication();
البته اگر از سیستم Identity استفاده می‌کنید، مورد اول به صورت خودکار با فراخوانی متد AddIdentity تنظیم شده‌است. فقط مورد دوم را هم باید اضافه کنید.

زمانی متد CallBackResult فراخوانی می‌شود و از فیلتر Authorize رد خواهید شد که کار اعتبارسنجی کاربر با موفقیت صورت گرفته باشد (همان
AutomaticAuthenticate و AutomaticChallenge فوق). بنابراین اگر تنظیمات اولیه‌ی Identity شما به درستی انجام شده باشد، صرفا مشکل مسیریابی را دارید که مقادیر را نال دریافت می‌کنید.
اشتراک‌ها
ReScript زبان پس از TypeScript؟

In the confusing jungle of transpiler languages for JavaScript, there are some gems. TypeScript is mainstream, ReScript is starting to establish itself, and Elm is still an insider tip. This article takes a detailed look at ReScript – but also sheds light on the limitations of the young language. In what projects does its use make sense? What projects should rather use TypeScript on the one hand or Elm on the other? 

ReScript زبان پس از TypeScript؟
مطالب
برنامه نویسی موازی - بخش اول - مفاهیم

برنامه نویسی موازی، نقطه‌ی متقابل برنامه نویسی سریال که حتی گاها با برنامه نویسی سریال به سبک Asynchronous به اشتباه گرفته می‌شود، به سبکی از برنامه نویسی گفته می‌شود که در آن برنامه نویس قابلیت اجرای بخش‌های موازی برنامه را از طریق چندین Thread و به طور همزمان ایجاد کرده باشد. نکاتی که در این سبک برنامه نویسی بسیار مهم است، مهارت‌های برنامه نویس در درک قسمت‌های موازی برنامه و مجزا سازی این بخش‌ها از یکدیگر است تا کمترین ارتباط را با هم داشته باشند. مشخصا تمامی یک برنامه قابلیت موازی سازی را نخواهد داشت؛ اما مفهومی به عنوان درجه‌ی موازی سازی در هر برنامه وجود دارد که ایده آل موازی سازی، رسیدن به این درجه‌ی از موازی سازی است.
در برنامه نویسی موازی، قسمت‌هایی از برنامه که به Thread‌های مجزایی برای اجرا محول شده‌اند، می‌توانند تقریبا در یک زمان شروع به اجرا کنند و اینگونه است که سرعت اجرای عملیات افزایش پیدا می‌کند. به عنوان مثال فرض کنید برنامه‌ای داریم که ۱۰۰ رکورد از پایگاه داده واکشی می‌کند و بررسی‌ای بر روی یکی از فیلدهای آن انجام می‌دهد که ۳ ثانیه زمان گیر است و در صورت وجود شرایط خاصی، آن رکورد را لاگ می‌کند. در برنامه نویسی سریال، برسی ۱۰۰ رکورد، به ۳۰۰ ثانیه زمان برای انجام احتیاج دارد؛ ولی با فرض انجام همین عملیات با دو Thread به صورت موازی، این زمان تقریبا به نصف کاهش پیدا خوهد کرد.


چرا و در چه زمانی باید به سراغ برنامه نویسی موازی رفت !؟


نرم افزارهای بزرگ با تعداد تراکنش‌های بالا و حجم اطلاعات بالا که همواره نیازمند پردازش مستمر هستند، لزوم استفاده‌ی بهینه از قدرت پردازشی پردازنده‌ها را ایجاب می‌کنند. به طور کل می‌توان گفت قسمت‌هایی از برنامه که عملیات پردازشی را روی داده‌های مجزا انجام می‌دهند، بهترین بخش برای انجام عملیات به صورت موازی و همزمان هستند. البته نباید این نکته را نیز فراموش کرد که عملیات ایجاد Thread و مدیریت آن‌ها، دارای سربار است. ازین‌رو بهتر است برای کارهای ساده و کوچک، به سراغ برنامه نویسی موازی نرفت.


در اجرای موازی بخش‌های مختلف برنامه، ترتیب انجام هر بخش نباید در نتیجه‌ی کلی تاثیر گذار باشد. در عملیات جمع یک مجموعه می‌توان آن را به چند Thread مجزا محول کرد تا هر بخش از مجموعه را یک Thread جمع بزند و در نهایت نتیجه‌ی کل Thread‌ها با هم جمع شود. در این عملیات ترتیب اتمام کار هر Thread، نتیجه‌ای بر Thread‌های دیگر و نتیجه‌ی نهایی، نخواهد داشت. اما در شکل بالا بعد از اتمام انجام عملیات تبدیل حروف کوچک به بزرگ توسط هر Thread، گارانتی‌ای برای چاپ آنها به همان ترتیبی که از سورس خوانده شده‌اند، وجود ندارد. به عبارتی ممکن است در ابتدا وظیفه‌ی 2 Thread تمام شده باشد و بعد 1 Thread که باعث خواهد شد در خروجی، ابتدا کاراکترهای "CD" و سپس "AB"  نمایش داده شود. البته این یک مثال ساده برای درک موضوع است.


مفهوم Thread Safe

Thread Safe یک مفهوم مرتبط به زبان‌های برنامه نویسی با قابلیت اجرای چند ریسمانی می‌باشد؛ بدین مفهوم که Thread safe فقط در نرم افزارهایی که به صورت Multi Thread نوشته شده‌اند معنا پیدا می‌کند.
درک مفهوم Thread Safe و تکنیک‌های مرتبط با آن، در نرم افزار‌های چند ریسمانی بسیار حائز اهمیت می‌باشد. چرا که باعث بروز برخی خطاهای منطقی در عملکرد سیستم خواهد شد که بعضاً ردگیری آن‌ها نیز بسیار دشوار است. به طور کلی هنگامیکه thread‌‌های مختلفی در یک برنامه در حال کار همزمان می‌باشند، رخ دادن دو اتفاق شایع زیر دور از ذهن نیست:


1- Dead Lock

مفهوم بن بست در علوم کامپیوتر، یکی ار رایج‌ترین مفاهیم است که از سطح سیستم عامل تا سیستم‌های توزیع شده، تعمیم داده می‌شود. Dead Lock  زمانی رخ می‌دهد که Thread‌های مختلف، با منابع مشترکی کار می‌کنند. بدین صورت که Thread شماره ۱، منبع A را در اختیار دارد و منتظر منبع B است. همزمان Thread شماره دو، منبع B را در اختیار دارد و منتظر منبع A است. به این شرایط، بن بست می‌گویند. شبیه سازی این اتفاق را در کد #C زیر می‌توانید ببینید:
public static void Function_A()
{
 lock (resource_1)
 {
   Thread.Sleep(1000);
   lock (resource_ 2)
   {
   }
 }
}

public static void Function_B()
{
 lock (resource_2)
 {
   Thread.Sleep(1000);
   lock (resource_1)
   {
   }
 }
}

static void Main()
{
  Thread thread_A = new Thread((ThreadStart)Function_A);
  Thread thread_B = new Thread((ThreadStart)Function_B);

  thread_A.Start();
  thread_B.Start();

  while (true)
  {
   // Stare at the two threads in deadlock.
  }
}

2- Race conditions

زمانی رخ می‌دهد که دو یا چند thread به یک مقدار مشترک دسترسی داشته باشند و تلاش کنند که در یک زمان، مقدار آن را تغییر دهند. مشکل از جایی رخ می‌دهد که شما به عنوان یک برنامه نویس نمی‌دانید، در یک زمان یکسان، برای تغییر یه مقدار مشترک بین thread‌ها، اولویت با کدام thread است. این اولویت بندی و جابجایی بین threadها وظیفه‌ی الگوریتم زمان بندی thread‌ها است که در هر زمان می‌تواند بین thread‌های مختلف سوییچ کند. این اولویت بندی می‌تواند روی عملکرد کد شما تاثیر گذار باشد؛ مخصوصا در بخش‌هایی که مقدار مشترکی برسی می‌شوند؛ مانند مثال زیر:
if (x == 5) 
{
   y = x * 2; 
}

اگر بلافاصله بعد از بررسی مقدار متغیر x توسط یک thread ،thread دیگری این مقدار را تغییر دهد، دیگر نتیجه‌ی این بلاک کد، منطقی نخواهد بود و جواب، ۱۰ نخواهد شد.

با توجه به مفاهیم عنوان شده، بررسی Thread safe بودن یک کد، با معیارهای زیر انجام می‌شود:
۱- قفل گذاری روی منابع باید به شکلی باشد که باعث بروز Dead Lock نشود.
۲- استفاده از مقادیر مشترک باید به گونه‌ای باشد که منجر به Race-conditions نشود.

حال اگر در هر برنامه، مقادیر مشترکی بین thread‌‌ها وجود داشته باشد، چه از نوع struct, class, static و ...  باید به این نکته توجه کرد که ذاتا این مقادیر Thread Safe هستند یا نه !؟ در بخش بعدی، راهکارهای قفل گذاری را برای استفاده از مقادیری که ذاتا thread safe نیستند، بررسی می‌کنیم.
نظرات مطالب
یک دست سازی ی و ک در برنامه‌های Entity framework 6
اصلاحیه برای SQLite

EF Core یکسری از نوع‌ها را مانند bool و DateTime به صورت رشته‌ای در SQLite ذخیره می‌کند. به همین جهت سطر زیر در PersianYeKeCommandInterceptor فوق، سبب از کار افتادن این نوع‌ها می‌شود؛ چون برای مثال DateTime را هم تبدیل به رشته می‌کند (پیش از موعد و با فرمتی که مدنظر EF Core نیست):
parameter.Value =   parameter.Value is DBNull ? parameter.Value : parameter.Value.ToString().ApplyCorrectYeKe();
روش اصلاح شده‌ی آن به صورت زیر است که رشته‌ای بودن خود Value را هم بررسی می‌کند:
if (!(parameter.Value is DBNull) && parameter.Value is string)
{
   parameter.Value =  Convert.ToString(parameter.Value, CultureInfo.InvariantCulture).ApplyCorrectYeKe();
}
مطالب
آشنایی با ساختار IIS قسمت اول
در مقاله قبل در مورد نحوه ذخیره سازی در حافظه نوشتیم و به user mode و kernel mode اشاراتی کردیم که می‌توانید به آن رجوع کنید.
در این سری مقالات قصد داریم به بررسی اجزا و روند کاری موجود در IIS بپردازیم که چگونه IIS کار می‌کند و شامل چه بخش هایی می‌شود. مطمئنا آشنایی با این بخش‌ها در روند شناسایی رفتارهای وب اپلیکیشن‌ها و واکنش‌های سرور، کمک زیادی به ما خواهد کرد. در اینجا نسخه IIS7 را به عنوان مرجع در نظر گرفته‌ایم.
وب سرور IIS در عبارت مخفف Internet information services به معنی سرویس‌های اطلاعاتی اینترنت می‌باشد. IIS شامل کامپوننت‌های زیادی است که هر کدام ازآن‌ها کار خاصی را انجام میدهند؛ برای مثال گوش دادن به درخواست‌های ارسال شده به سرور، مدیریت فرآیندها Process و خواندن فایل‌های پیکربندی Configuration؛ این اجزا شامل protocol listener ،Http.sys و WSA و .. می‌شوند.
Protocol Listeners
این پروتکل‌ها به درخواست‌های رسیده گوش کرده و آن‌ها را مورد پردازش قرار می‌دهند و پاسخی را به درخواست کننده، ارسال می‌کنند. هر listener بر اساس نوع پروتکل متفاوت هست. به عنوان مثال کلاینتی، درخواست صفحه‌ای را می‌کند و http listener که به آن Http.sys می‌گویند به آن پاسخ می‌دهد. به طور پیش فرض http.sys به درخواست‌های http و https گوش فرا می‌دهد، این کامپوننت از IIS6 اضافه شده است ولی در نسخه 7 از SSL نیز پشتیبانی می‌کند.
Http.sys یا Hypertext transfer protocol stack
کار این واحد در سه مرحله دریافت درخواست، ارسال آن به واحد پردازش IIS و ارسال پاسخ به کلاینت است؛ قبل از نسخه 6 از Winsock یا windows socket api  که یک کامپوننت user-mod بود استفاده می‌شد ولی Http.sys یک کامپوننت Kernel-mod هست.

Http.sys مزایای زیر را به همراه دارد:

  • صف درخواست مد کرنل: به خاطر اینکه کرنل مستقیما درخواست‌ها را به پروسه‌های مربوطه میفرستد و اگر پروسه موجود نباشد، درخواست را در صف گذاشته تا بعدا پروسه مورد نظر آن را از صف بیرون بکشد.
  • برای درخواست‌ها یک پیش پردازش و همچنین اعمال فیلترهای امنیتی اعمال می‌گردد. 
  • عملیات کش کردن تماما در محیط کرنل مد صورت می‌گیرد؛ بدون اینکه به حالت یوزرمد سوییچ کند. مد کرنل دسترسی بسیار راحت و مستقیمی را برای استفاده از منابع دارد و لازم نیست مانند مد کاربر به لایه‌های زیرین، درخواست کاری را بدهد؛ چرا که خود مستقیما وارد عمل می‌شود و برداشته شدن واسط در سر راه، موجب افزایش عمل caching می‌شود. همچنین دسترسی به کش باعث می‌شود که مستقیما پاسخ از کش به کاربر برسد و توابع پردازشی در حافظه بارگذاری نشوند. البته این کش کردن محدودیت هایی را هم به همراه دارد:
    1. کش کرنل به صورت پیش فرض بر روی صفحات ایستا فعال شده است؛ نه برای صفحاتی با محتوای پویا که البته این مورد قابل تغییر است که نحوه این تغییر را پایینتر توضیح خواهیم داد.
    2. اگر آدرس درخواستی شامل کوئری باشد صفحه کش نخواهد شد:    http://www.site.info/postarchive.htm?id=25 
    3. برای پاسخ ازمکانیزم‌های فشرده سازی پویا استفاده شده باشد مثل gzip کش نخواهد شد
    4. صفحه درخواست شده صفحه اصلی سایت باشد کش نخواهد شد :   http://www.dotnettip.info ولی اگر درخواست بدین صورت باشه http://www.domain.com/default.htm  کش خواهد کرد.
    5. درخواست به صورت ناشناس anonymous نباشد  و نیاز به authentication داشته باشد کش نخواهد شد (یعنی در هدر شامل گزینه authorization می‌باشد).
    6. درخواست باید از نوع نسخه http1 به بعد باشد.
    7. اگر درخواست شامل Entity-body باشد کش نخواهد کرد.
    8. درخواست شامل If-Range/Range header باشد کش نمی‌شود.
    9. کل حجم response بییشتر از اندازه تعیین شده باشد کش نخواهد گردید، این اندازه در کلید ریجستری UriMaxUriBytes قرار دارد. اطلاعات بیشتر
    10. اندازه هدر بیشتر از اندازه تعیین شده باشد که عموما اندازه تعیین شده یک کیلو بایت است.
    11. کش پر باشد، کش انجام نخواهد گرفت.
    برای فعال سازی کش کرنل راهنمای زیر را دنبال کنید:
    گزینه output cache را در IIS، فعال کنید و سپس گزینه Add را بزنید. کادر add cache rule که باز شود، از شما میخواهد یکی از دو نوع کش مد کاربر و مد کرنل را انتخاب کنید و  مشخص کنید چه نوع فایل‌هایی (مثلا aspx) از این قوانین پیروری کنند و مکانیزم کش کردن به سه روش جلوگیری از کش کردن، کش زمان دار و کش بر اساس آخرین تغییر فایل انجام گردد.


    برای تعیین مقدار سایز کش response که در بالا اشاره کردیم می‌توانید در همان پنجره، گزینه edit feature settings را انتخاب کنید.


    این قسمت از مطلب که به نقل از مقاله  آقای Karol Jarkovsky در این آدرس است یک سری تست هایی با نرم افزار(Web Capacity Analysis Tool (WCAT  گرفته است که به نتایج زیر دست پیدا کرده است:
    Kernel Cache Disabled    4 clients/160 threads/30 sec      257 req/sec
    Kernel Cache Enabled     4 clients/160 threads/30 sec      553 req/sec 
    همانطور که می‌بینید نتیجه فعال سازی کش کرنل پاسخ به بیش از دو برابر درخواست در حالت غیرفعال آن است که یک عدد فوق العاده به حساب میاد.
    برای اینکه خودتان هم تست کرده باشید در این آدرس  برنامه را دانلود کنید و به دنبال فایل request.cfg بگردید و از صحت پارامترهای server و url اطمینان پیدا کنید. در گام بعدی 5 پنجره خط فرمان باز کرده و در یکی از آن‌ها دستور netsh http show cachestate را بنویسید تا تمامی وروردی‌های entry که در کش کرنل ذخیره شده اند لیست شوند. البته در اولین تست کش را غیرفعال کنید و به این ترتیب نباید چیزی نمایش داده شود. در همان پنجره فرمان wcctl –a localhost –c config.cfg –s request.cfg  را زده تا کنترلر برنامه در وضعیت listening قرار بگیرد. در 4 پنجره دیگر فرمان wcclient localhost از شاخه کلاینت را نوشته تا تست آغاز شود. بعد از انجام تست به شاخه نصب کنترلر WCAT رفته و فایل log را بخوانید و اگر دوباره دستور نمایش کش کرنل را بزنید باید خالی باشد. حالا کش را فعال کنید و دوباره عملیات تست را از سر بگیرید و اگر دستور netsh را ارسال کنید باید کش کرنل دارای ورودی باشد.
    برای تغییرات در سطح http.sys می‌توانید از ریجستری کمک بگیرید. در اینجا تعداد زیادی از تنظیمات ذخیره شده در ریجستری برای http.sys لیست شده است.