IIS7은 Response.StatusCode를 설정할 때 customErrors를 무시합니까?

IIS7은 Response.StatusCode를 설정할 때 customErrors를 무시합니까?

---

여기에 이상한 문제가 있습니다. web.config customErrors섹션을 사용하여 사용자 지정 오류 페이지를 만들면 Response.StatusCode적절한 것으로 설정해야한다는 것을 누구나 알고 있습니다 . 예를 들어 사용자 지정 404 페이지를 만들고 이름을 404.aspx로 지정 <% Response.StatusCode = 404 %>하면 내용을 입력하여 실제 404 상태 헤더를 가질 수 있습니다.

지금까지 나를 따라와? 좋은. 이제 IIS7에서 이것을 시도하십시오. 나는 그것을 작동시킬 수 없다. Response.StatusCode사용자 지정 오류 페이지에이 설정되어 있으면 IIS7은 사용자 지정 오류 페이지를 완전히 무시하고 자체 상태 페이지를 표시합니다 (구성된 경우).

이 동작을 본 사람이 있고 해결 방법을 알고있는 사람이 있습니까? IIS6에서 작동했기 때문에 상황이 변경된 이유를 모르겠습니다.

참고 : 이것은 404 Not Found 대신 200 OK를 반환하는 ASP.NET Custom 404 의 문제와 동일 하지 않습니다.

---

system.webServer / httpErrors 섹션에서 existingResponse를 PassThrough로 설정합니다.

  <system.webServer>
    <httpErrors existingResponse="PassThrough" />
  </system.webServer>

existingResponse 속성의 기본값은 Auto입니다.

Auto는 사용자 정의 오류 모듈에 올바른 작업 을 수행하도록 지시 합니다. 클라이언트에 표시되는 실제 오류 텍스트는 IHttpResponse::GetStatus호출 에서 반환 된 fTrySkipCustomErrors 값에 따라 영향을받습니다 . fTrySkipCustomErrors가 true로 설정되면 사용자 정의 오류 모듈이 응답을 통과하도록 허용하지만 false로 설정하면 사용자 정의 오류 모듈이 텍스트를 자체 텍스트로 대체합니다.

추가 정보 : IIS7 사용자 지정 오류 모듈에서 기대할 수있는 사항

---

동작을 일관되게 만드는 가장 쉬운 방법은 오류를 지우고 Response.TrySkipIisCustomErrors 를 사용하고이를 true로 설정하는 것입니다. 이는 페이지 내에서 처리되는 IIS 전역 오류 페이지 또는 Application_Error의 전역 오류 처리기를 재정의합니다.

Server.ClearError();
Response.TrySkipIisCustomErrors = true;

일반적으로 애플리케이션 오류 핸들러가 포착하지 못하는 모든 오류를 처리하는 Application_Error 핸들러에서이 작업을 수행해야합니다.

더 자세한 정보는 다음 블로그 게시물에서 찾을 수 있습니다. http://www.west-wind.com/weblog/posts/745738.aspx

---

해결됨 : IIS7에서 오류 페이지를 "통과"하려면 "상세 오류"가 켜져 있어야합니다. http://forums.iis.net/t/1146653.aspx 참조

---

이것이 본질적으로 유사한 지 아닌지는 확실하지 않지만 표면적으로 비슷하게 들리는 문제를 해결했으며 여기에 처리 방법이 있습니다.

우선, existingResponse (Auto)의 기본값이 제 경우에는 정답이었습니다. 사용자 지정 404, 400 및 500이 있기 때문입니다 (다른 항목을 만들 수도 있지만이 세 가지로 충분합니다). 저에게 도움이 된 관련 섹션은 다음과 같습니다.

web.config에서 :

<customErrors mode="Off" />

과

<httpErrors errorMode="Custom" existingResponse="Auto" defaultResponseMode="ExecuteURL">
  <clear />
  <error statusCode="404" path="/errors/404.aspx" responseMode="ExecuteURL" />
  <error statusCode="500" path="/errors/500.aspx" responseMode="ExecuteURL" />
  <error statusCode="400" path="/errors/400.aspx" responseMode="ExecuteURL" />
</httpErrors>

거기에서 나는 이것을 global.asax의 Application_Error에 추가했습니다.

    Response.TrySkipIisCustomErrors = True

각 사용자 지정 오류 페이지에 올바른 응답 상태 코드를 포함해야했습니다. 제 경우에는 사용자 지정 404를 사용하여 사용자를 내 사이트의 다른 섹션으로 보내고 있으므로 실제로 죽은 페이지가 아닌 한 404 상태 코드가 반환되는 것을 원하지 않습니다 .

어쨌든, 그렇게 했어요. 누군가에게 도움이되기를 바랍니다.

---

이 문제는 큰 골칫거리였습니다. 이전에 언급 한 제안 중 어느 것도 나에게 해결되지 않았으므로 내 솔루션을 포함하고 있습니다. 기록을 위해 우리의 환경 / 플랫폼은 다음을 사용합니다.

• .NET Framework 4
• MVC 3
• IIS8 (워크 스테이션) 및 IIS7 (웹 서버)

특히 사용자를 Web.config 설정을 통해 사용자 지정 404 페이지로 리디렉션하는 HTTP 404 응답을 얻으려고했습니다.

첫째, 내 코드는 HttpException. NotFoundResult컨트롤러에서 a 를 반환 해도 내가 원하는 결과를 얻지 못했습니다.

throw new HttpException(404, "There is no class with that subject");

그럼 구성해야했습니다 모두customErrors 와 httpError의 Web.config의 노드.

<customErrors mode="On" defaultRedirect="/classes/Error.aspx">
  <error statusCode="404" redirect="/classes/404.html" />
</customErrors>

...

<httpErrors errorMode="Custom" existingResponse="Auto" defaultResponseMode="ExecuteURL">
  <clear />
  <error statusCode="404" path="/classes/404.aspx" responseMode="ExecuteURL" />
</httpErrors>

참고 난을 떠났다 existingResponse로 Auto제공되는 솔루션 @sefl 다른이다.

The customErrors settings appeared to be necessary for handling my explicitly thrown HttpException, while the httpErrors node handled URLs that fell outside of the route patterns specified in Globals.asax.cs.

P.S. With these settings I did not need to set Response.TrySkipIisCustomErrors

---

TrySkipIisCustomErrors is only a part of a puzzle. If you use Custom Error Pages but you also want to deliver some RESTful content based on 4xx statuses then you have a problem. Setting web.config's httpErrors.existingResponse to "Auto" does not work, because .net seems to always deliver some page content to IIS, therefore using "Auto" causes all (or at least some) Custom Error Pages to be not used. Using "Replace" won't work too, because response will contain your http status code, but its content will be empty or filled with Custom Error Page. And the "PassThrough" in fact turns the CEP off, so it can't be used.

So if you want to bypass CEP for some cases (by bypassing I mean returning status 4xx with some content) you will need additional step: clean the error:

void Application_Error(object sender, EventArgs e)
{
    var httpException = Context.Server.GetLastError() as HttpException;
    var statusCode = httpException != null ? httpException.GetHttpCode() : (int)HttpStatusCode.InternalServerError;

    Context.Server.ClearError();
    Context.Response.StatusCode = statusCode;
}

So if you want to use REST response (i.e. 400 - Bad Request) and send some content with it, you will just need to set TrySkipIisCustomErrors somewhere in action and set existingResponse to "Auto" in httpErrors section in web.config. Now:

• when there's no error (action returns 4xx or 5xx) and some content is returned the CEP is not used and the content is passed to client;
• when there's an error (an exception is thrown) the content returned by error handlers is removed, so the CEP is used.

If you want to return status with empty content from you action it will be treated as an empty response and CEP will be shown, so there's some room to improve this code.

---

By default IIS 7 uses detailed custom error messages so I would assume that Response.StatusCode will equal 404.XX rather than just 404.

You can configure IIS7 to use the simpler error message codes or modify your code handling the more detailed error messages that IIS7 offers.

More info available here: http://blogs.iis.net/rakkimk/archive/2008/10/03/iis7-enabling-custom-error-pages.aspx

Further investigation revealed I had it the wrong way around - detailed messages aren't by default but perhaps they've been turned on, on your box if you're seeing the different error messages that you've mentioned.

참고URL : https://stackoverflow.com/questions/434272/iis7-overrides-customerrors-when-setting-response-statuscode