5

So I have a small snippet of code.

string requestedUrl = args.Context.Request.Url.AbsoluteUri;
Log.Warn($"Requested Url: '{requestedUrl}' being checked.", this);
var redirectTarget = _redirector.GetRedirectTarget(mapKey, requestedUrl.ToLowerInvariant());
if (!string.IsNullOrEmpty(redirectTarget))
{
    Log.Warn($"Map 301 redirected '{args.Context.Request.Url.AbsoluteUri}' => {redirectTarget}", this);
    args.AbortPipeline();
    args.Context.Response.RedirectPermanent(redirectTarget);
}

And my problem is this; because the RedirectPermanent() call essentially works by throwing an exception - nothing gets logged on those requests. Which is what surprises me. I would expect the Log.Warn($"Map 301... log entry to always show up in my Sitecore log - but it doesn't.

The only log entries I get with this code, are like these:

31264 13:13:14 WARN Requested Url: 'http://myclient.dk/collections/myclientproduct' being checked.

Which is one of the target URLs in my code. The request that happened just prior, that was redirected to this page - is not shown in log.

What gives? And this must have been changed recently, no? I am almost certain, this behaviour wasn't always like this.

Edited to add

This code lives in a HttpRequestProcessor that is patched in right after the DatabaseResolver in the <httpRequestBegin> pipeline. While I don't know why, this seems to make a difference. Executing the above code in a normal page, works as expected.

9

It's not the problem with the Log.Warn being called in a httpRequestBegin processor or from a normal page. It's just your browser caching the redirect.

First time you do a call to a page which should be redirected, you will see the log entry starting from:

Map 301 redirected...

in your log files. Second time you do the same request in your browser, it won't even hit your server. It's cached in your browser, cause you're using 301 permanent redirect. You'll be redirected, but nothing will be saved in your logs.

| improve this answer | |
  • 1
    D'oh. And indeed you are right. I was SO focused on two things; the Redirect which I know aborts the page execution, and the fact I was early in the request pipeline that perhaps the dependency injection of the logger wasn't set up correctly. It never occurred to me that the requests I was sitting here testing, simply never made it to the server. Goes to show; debugging a problem is 99% looking in the right places and 1% fixing ;-) – Mark Cassidy Nov 3 '17 at 14:24
2

You can try and use the second overload of RedirectPermanent(string, boolean) , where you can tell IIS pipeline not to throw an exception by setting endResponse= false:

args.Context.Response.RedirectPermanent(redirectTarget, false);

Combine this with calling CompleteRequest() will ensure that once the current page/pipeline finishes, it will go to EndRequest event, So your code should be like this :

args.Context.Response.RedirectPermanent(redirectTarget, false);
args.Context.ApplicationInstance.CompleteRequest();

You can find more details on this here

| improve this answer | |
  • 1
    I was completely thinking along these lines as well. Turns out I was looking in all the wrong places for my root cause. That said - your answer is still useful, I will take a deeper look at how the redirection is ultimately handled. – Mark Cassidy Nov 3 '17 at 14:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.