O URL de reescrita .htaccess leva à falta de CSS

Eu estou tentando fazer meu URL a partir disso:

example.com/view.php?id=15

Para isso:

example.com/watch/15

Meu código .htaccessé o seguinte:

Options -Indexes
Options +FollowSymlinks
RewriteEngine On
RewriteRule ^watch/([^/]+) view.php?id=$1 [NC]

Agora, se eu for example.com/watch/15carregar o conteúdo, mas sem JS, CSS, porque neste caso ele procura CSS e JS na /watchpasta que não existe.

Como faço para que esta opção funcione corretamente? Não quero criar uma pasta monitorada e copiar e colar CSS e JS para que ele seja incorporado corretamente.

Não conseguir encontrar seus arquivos JavaScript e CSS é um problema do lado do cliente / navegador relacionado ao seu caminho de URL, não é algo que deve ser corrigido .htaccess(pelo menos não neste caso) - embora seja porque você está alterando isso Caminho da URL (in .htaccess) em que você está enfrentando esse problema.

Como o @closetnoc sugeriu nos comentários, esse problema é causado pelo uso de URLs relativos no seu HTML. Em relação a quê? Lembre-se, é o agente / navegador do usuário que resolve os URLs relativos no seu HTML, não no servidor. Então, você precisa corrigir seus URLs; não .htaccess.

Por exemplo, se você estiver referenciando seu arquivo CSS com uma URL relativa do formulário href="styles.css"(observe, sem prefixo de barra) e você estiver atualmente na URL example.com/view.php?id=15, o navegador resolverá naturalmente sua URL e solicitação CSS example.com/styles.css(na raiz do documento). No entanto, se você está atualmente na URL example.com/watch/15(efetivamente em um /watch"subdiretório" ^{[* 1]} ), então o navegador irá resolver o seu parente CSS URL relativa a um /watchsubdiretório, ao invés da raiz do documento, assim você acaba com um absoluto / resolvido URL do formulário example.com/watch/styles.css.

( ^{[* 1]} Observe que "subdiretório" nesse contexto não é necessariamente um subdiretório físico no servidor - é um "subdiretório" no caminho da URL; um segmento de caminho adicional. Mas o navegador não sabe a diferença. )

O mesmo se aplica se você estiver usando URLs relativos em seus documentos de erro personalizados (definidos com a ErrorDocumentdiretiva no Apache). O documento de erro personalizado pode potencialmente ser chamado em qualquer URL, portanto, qualquer URL relativo a um recurso estático (CSS, imagem, JS etc.) será relativo à URL que causou o erro, não ao próprio documento de erro (cuja localização está efetivamente oculta do agente do usuário).

Se você alterasse seus URLs JavaScript e CSS para serem relativos à raiz (começando com uma barra) ou mesmo absolutos, não haveria esse problema. Este seria o método preferido. Como alternativa, você pode usar o baseelemento ...

base tag / elemento

Como alternativa, você pode incluir um baseelemento na headseção do seu documento HTML (embora isso não ocorra sem suas ressalvas ^{[* 2]} ). Isso faz referência ao URL absoluto ao qual todos os URLs relativos são relativos . Em outras palavras, como você espera que esses URLs relativos sejam relativos à raiz do documento, adicione o seguinte à headseção:

<base href="http://example.com/">

Agora, um URL relativo, como styles.cssmencionado em um documento no URL /watch/15, solicitará http://example.com/styles.css, não http://example.com/watch/styles.css.

^{[* 2]} No entanto, existem algumas ressalvas no uso dobaseelemento. Uma preocupação principal é que qualquerURL relativo destinado aodocumento atual agora terá como alvo o URL base. Isso pode afetar âncoras in-page comohref="#top"e URLs do formuláriohref="?sortby=date"etc. E tambémformelementos que se submetem usando umactionatributovazio(por exemplo,<form action="" ...). Esses URLs relativos que segmentam o documento atual precisarão ser modificados para incluir o URL completo da página atual (o que pode prejudicar o ponto de usar abasetag como uma solução alternativa para começar).

Referência:

• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/base
• /programming/1889076/what-are-the-recommendations-for-html-base-tag