2013-03-25 2 views
3

Я взял следующий код из Stackoverflow-> в блог, который обрабатывает пользовательский 404 в Sitecore (который фактически перенаправляет 302 на страницу 404 со статусом 200, который получает google как soft 404) ,Обработчик Sitecore custom 404 в производстве

Несмотря на то, что это хорошо работает на наших локальных тестовых серверах, в тот момент, когда мы бросаем его на производство, сайт переходит на haywire и принимает AGES, например. 8-9 минут для загрузки и прочее.

public class ExecuteRequest : Sitecore.Pipelines.HttpRequest.ExecuteRequest 
{ 
    protected override void RedirectOnItemNotFound(string url) 
    { 
     var context = System.Web.HttpContext.Current; 

     try 
     { 
      // Request the NotFound page 
      var domain = context.Request.Url.GetComponents(
       UriComponents.Scheme | UriComponents.Host, 
       UriFormat.Unescaped); 

      var content = WebUtil.ExecuteWebPage(
       string.Concat(domain, url)); 

      // The line below is required for IIS 7.5 hosted 
      // sites or else IIS is gonna display default 404 page 
      context.Response.TrySkipIisCustomErrors = true; 
      context.Response.StatusCode = 404; 
      context.Response.Write(content); 
     } 
     catch (Exception ex) 
     { 
      Log.Error(string.Format("Falling back to default redirection behavior. Reason for error {0}", ex), ex); 

      // Fall back to default behavior on exceptions 
      base.RedirectOnItemNotFound(url); 
     } 

     context.Response.End(); 
    } 
} 

P.S: Я заменил ExecuteRequest своим обычным в web.config.

Если вы испытали подобную вещь или знаете о какой-либо проблеме, пожалуйста, проведите некоторый свет.

Заранее спасибо

+0

Я бы подумал, что вызов в WebUtil.ExecuteWebPage будет проблематичным во всем, что связано с этим легким трафиком. Слишком много запросов обратной связи с обратной связью. Если ваша страница 404 каким-то образом вызывает 404 себя, вы можете попасть в цикл (возможно, это то, что происходит?) –

ответ

6

Существует параметр в Sitecore, с помощью которого можно избавиться от 302 редиректа:

<setting name="RequestErrors.UseServerSideRedirect" value="true" /> 

С помощью этой настройки, URL-адрес остается неизменным и код состояния 404. Если вы хотите иметь некоторую дополнительную логику (например, показать элемент Sitecore как страницу с ошибкой), на модуле Sitecore Market Place имеется модуль общего источника, называемый диспетчером ошибок.

Надеюсь, что это поможет.

+0

Это работает, пока ваша страница 404 - это файл, а не элемент Sitecore. –

+0

Менеджер ошибок Sitecore обрабатывает файл 404 с файлом, который отображает элемент Sitecore. И таким образом вы можете взять товар в качестве страницы 404 и использовать указанные выше настройки, чтобы избавиться от 302. –

0

Проверьте, имеет ли сервер доступ к имени вашего сайта.

Серверы часто не имеют доступа к DNS и поэтому не могут разрешать имена хостов. Чтобы ваш обработчик 404 работал, приложение должно иметь доступ к собственному имени хоста, чтобы запросить страницу 404.

Чтобы быть уверенным, что это работает, редактировать hosts файл сервера и добавить запись для имени хоста там, указывая его на 127.0.0.1

0

Вы можете решить это с созданием нового распознаватель. Это хорошее решение, когда вы хотите указать страницу с ошибкой пользователя на правильном языке. Но есть некоторые отличия в IIS 7.0 и 7.5.

Добавить процессор конфигурации Sitecore:

<processor type="Sitecore.Pipelines.HttpRequest.ItemResolver, Sitecore.Kernel"/> 
<processor type="Project.Error404Resolver, Project" /> 

процессора его разрешения:

Для IIS 7.0:

public class Error404Resolver : Sitecore.Pipelines.HttpRequest.HttpRequestProcessor 
{ 
    public override void Process(Sitecore.Pipelines.HttpRequest.HttpRequestArgs args) 
    { 
     if(Sitecore.Context.Item == null && !args.Context.Request.Url.AbsolutePath.StartsWith("/sitecore") 
     { 
      args.Context.Response.Clear(); 

      SiteContext site = Sitecore.Context.Site; 
      if(site != null) 
      { 
       Item item404Page = Sitecore.Context.Database.GetItem(site.RootPath + "website/error/404"); 
       if(item404Page != null) 
       { 
        Sitecore.Context.Item = item404Page; 
        args.Context.Response.StatusCode = (int) System.Net.HttpStatusCode.NotFound; 
       } 
      } 
     } 
    } 
} 

Для IIS 7.5:

public class Error404Resolver : Sitecore.Pipelines.HttpRequest.HttpRequestProcessor 
{ 
    public override void Process(Sitecore.Pipelines.HttpRequest.HttpRequestArgs args) 
    { 
     if(Sitecore.Context.Item == null && !args.Context.Request.Url.AbsolutePath.StartsWith("/sitecore") 
     { 
      args.Context.Response.Clear(); 

      SiteContext site = Sitecore.Context.Site; 
      if(site != null) 
      { 
       Item item404Page = Sitecore.Context.Database.GetItem(site.RootPath + "website/error/404"); 
       if(item404Page != null) 
       { 
        WebClient webClient = new WebClient(); 
        webClient.Encoding = args.Context.Request.ContentEncoding; 
        webClient.Headers.Add("User-Agent", args.Context.Request.UserAgent); 
        string page = webClient.DownloadString(LinkManager.GetItemUrl(item404Page)); 

        args.Context.Response.StatusCode = (int) System.Net.HttpStatusCode.NotFound; 
        args.Context.Response.Write(page); 
        args.Context.Response.TrySkipIisCustomErrors = true; 
        args.Context.Response.End(); 
       } 
      } 
     } 
    } 
} 

Уит это вы воздадите страницу ошибки в текущей странице без редиректа и возвращается в код браузера 404.

0

У меня есть один и тот же вопрос на клиенте я в настоящее время работаю в (выглядит как код был вставлен) и фактически причина довольно очевидна: если вы выполняете этот вызов с URL-адресом, который не зарегистрирован в конфигурации сайтов Sitecore (но доступен через IIS), вы также пропустите этот код. К сожалению, вызов WebUtil.ExecuteWebPage выполняется с неправильным URL-адресом, поэтому вы попадаете в цикл.

На самом деле вы должны увидеть много этих сообщений в своем журнале: Возврат к положению перенаправления по умолчанию. Причина ошибки {0}, возможно, с таймаутами.

Если вы действительно хотите использовать свой собственный обработчик, вы должны проверить, находитесь ли вы в правильном контексте сайта, прежде чем вызывать WebUtil.ExecuteWebPage.

Смежные вопросы