>  Q&A  >  본문

PHP 8로 마이그레이션한 후 htaccess 다시 쓰기 규칙이 작동하지 않습니다.

<p>PHP 7에서 PHP 8로 마이그레이션한 후 URL 재작성 규칙에 문제가 발생했습니다. </p> <p>htaccess 위에 다음 코드가 있습니다</p> <pre class="brush:php;toolbar:false;">옵션 +FollowSymLinks RewriteEngine 켜기 RewriteBase /baba/ ErrorDocument 404 http://localhost/baba/404.php</pre> <올> <li>검색 페이지:-</li> </ol> <p>다음 규칙을 사용하면 매우 효과적입니다: -</p> <pre class="brush:php;toolbar:false;">RewriteRule ^s/([w-]+)/(.*)$ search.php?feq=$1&key=$2 [QSA,L ]</pre> <p>그러나 아래와 같은 규칙을 더 추가하면 이 페이지에는 404가 표시됩니다. </p> <pre class="brush:php;toolbar:false;">RewriteRule ^s/([w-]+)/(.*)/(.*)$ search.php?feq=$1&city= $2&키=$3 [QSA,L] RewriteRule ^s/([w-]+)/(.*)/(.*)/(.*)$ search.php?feq=$1&pro=$2&city=$3&key=$4 [ QSA,L]</pre> <ol start="2">
  • 방문 페이지:-
  • </ol> <p>다음 규칙을 사용하면 매우 효과적입니다: -</p> <pre class="brush:php;toolbar:false;">RewriteRule ^([w-]+)$ land.php?name=$1 [QSA,L]</pre> <p>그러나 아래와 같은 규칙을 더 추가하면 CSS와 이미지가 다른 페이지에서 로드를 멈추고 해당 페이지에 404가 표시됩니다. </p> <pre class="brush:php;toolbar:false;">RewriteRule ^([w-]+)/(.*)/(.*)$ land.php?name=$1&pro=$2& ;도시=$3 [QSA,L] RewriteRule ^([w-]+)/(.*)$ land.php?name=$1&key=$2 [QSA,L] RewriteRule ^([w-]+)/(.*)/(.*) land.php?name=$1&city=$2&key=$3 [QSA,L] RewriteRule ^([w-]+)/(.*)/(.*)/(.*)$ land.php?name=$1&pro=$2&city=$3&key=$4 [QSA, L]</pre></p>
    P粉274161593P粉274161593435일 전552

    모든 응답(1)나는 대답할 것이다

  • P粉022501495

    P粉0225014952023-09-02 09:45:36

    이것은 PHP 버전과 관련이 없습니다. 규칙이 명백히 충돌합니다...

    첫 번째 규칙의 정규식은 너무 일반적이기 때문입니다(경로 세그먼트 수에 관계없이 /s/foo/),如果您简单地添加第二条规则,那么第一条规则仍然会捕获所有请求并重写为 search.php?feq=foo&key= 일치). 예를 들어 문자 그대로 any 가 아닌 전체 경로 세그먼트만 일치해야 합니다.

    으아악

    참고하세요 [^/](除 / 之外的任何内容)而不是 .(任何内容)。还可以在强制路径段中使用 +(1개 이상).

    원래 규칙과 마찬가지로 key URL 매개변수(예: 첫 번째 규칙의 두 번째 경로 세그먼트 및 후속 규칙의 마지막 경로 세그먼트)는 선택 사항입니다. 의도적인 걸까요?

    이러한 URL 매개변수에 허용되는 문자를 알고 있는 경우 정규식에 이러한 문자를 표시하여 URL을 추가로 제한해야 합니다. 그렇지 않으면 URL이 (잘못) 다시 작성됩니다.

    당면한 문제를 해결하기 위해 지침의 순서를 바꿀 수도 있지만 정규식은 여전히 ​​너무 일반적이므로 이는 부분적인 해결책일 뿐입니다.

    위에서 언급했듯이. 그러나 클라이언트 측 HTML에서 이러한 리소스에 대한 상대 URL 경로를 사용하면 CSS 및 이미지 오류가 발생할 수 있습니다. 다른 경로 깊이에서 요청을 다시 작성하므로 정적 리소스의 루트 상대(또는 절대) URL을 사용해야 합니다. 상대 URL은 브라우저 주소 표시줄의 URL을 기준으로 브라우저에 의해 자연스럽게 확인됩니다.

    (해결 방법으로 head 部分中设置 base 요소에 기본 URL 경로 relative를 전달하여 모든 상대 URL이 상대적임을 나타낼 수 있지만 주의 사항이 없는 것은 아닙니다.)

    손실된 자산에 대한 추가 자료:

    또한 "랜딩 페이지" 규칙은 "검색 페이지" 규칙 뒤에 와야 합니다. 그렇지 않으면 충돌도 발생합니다. 다시 말하지만, 정규식을 더욱 구체적으로 만들어 이러한 충돌을 피할 수 있습니다. 예를 들어 "랜딩 페이지"(name URL 参数的值)设置为 2 个或更多字符,而不是 1 个或更多字符,以避免与 / 冲突s/("검색"에서).

    의 첫 번째 경로 세그먼트를 변경하면 됩니다.

    나레이션:

    이렇게 하면 404 오류 문서로의 302(임시) 리디렉션이 실행됩니다(404 응답과 실제로 404를 실행한 URL이 마스킹됩니다). 이는 매우 구체적인 요구 사항이 없는 한 일반적으로 권장되지 않습니다. 여기서는 일반적으로 루트 상대 URL 경로를 사용해야 합니다. 예:

    으아악 그런 다음

    /baba/404.php는 내부 하위 요청을 통해 제공되며 오류 문서 자체는 최종 사용자에게 노출되지 않습니다.

    리디렉션을 사용하여 누락된 리소스 문제를 해결하는 경우 HTML 소스 코드에서 상대 URL을 사용하지 않는 것에 대한 위의 내용을 참조하세요.

    회신하다
    0
  • 취소회신하다