Apache serve página incorreta

3

Para o prefácio: isso tem que ser um dos bugs mais estranhos que eu já vi, especialmente desde que vem e vai.

Existe uma página chamada view.php e outra página chamada save.php . O bug se manifesta quando eu solicito save.php - em vez disso, eu obtenho view.php . Os cabeçalhos de solicitação dizem save.php , e isso acontece no Firefox, IE, Chrome, Opera, Safari. Isso acontece consistentemente a menos - e aqui está a parte estranha - eu abro o arquivo e o salvo. Eu não faço nenhuma alteração, apenas salve. Depois de salvar, posso fazer a mesma solicitação e exibir save.php como se nada estivesse errado.

Atualmente estou exportando de um repositório svn (apenas um simples comando svn export http://server/repository target ). Se eu exportar depois de não fazer nenhuma alteração, o bug é novamente manifestado. Se fizer uma alteração (em uma página totalmente não relacionada), e enviá-lo para o repositório, em seguida, exportar, o bug geralmente desaparece. No entanto, a mesma coisa pode acontecer com duas páginas diferentes (também não relacionadas à página alterada) ou não.

Não estou usando nenhum tipo de cache (sem cache do php, cache do navegador ou cache do apache).

Versões SVN: 1.6.9 w / AnkhSVN em uma máquina Windows (a máquina de desenvolvimento), 1.4.2 na máquina de repositório e na máquina de teste (onde eu executo o comando de exportação).

Além de suspeitar que o svn é onde algo está errado, não faço ideia.

    
por Andrew G 26.06.2010 / 00:19

3 respostas

1

Por que você não tenta renomear os arquivos? Renomeie os dois arquivos, adicione algum tipo de prefixo e tente novamente. Isso pode eliminar qualquer confusão ou redirecionamento defeituoso (talvez).

Certifique-se de que nenhum dos caches esteja ativado. Verifique seus módulos no Apache e descarregue qualquer módulo de cache. Certifique-se de que a extensão APC no PHP não esteja carregada (phpinfo)

Tente usar svn checkout em vez de svn export . Comece a testar e quando você perceber o comportamento do buggy, faça svn stat para ver se alguma coisa mudou. Tecnicamente, não deve haver diferença entre checkout e export , exceto que checkout é mais útil, pois permite atualizações in-loco. Mas com checkout você quer ter algo como seguir na sua configuração vhost.

<LocationMatch "\.svn.*">
 Order deny,allow
 Deny from all
</LocationMatch>

Por último, mas não menos importante, comece com a nova configuração HTTP. Configuração de backup e reinstalar seus pacotes Apache / PHP. Isso deve gerar a configuração padrão. Em seguida, adicione alterações de configuração simples para poder servir os arquivos PHP. Depois de ver os dois arquivos sem problemas, comece a testar seu problema. Em seguida, comece gradualmente a adicionar as partes de configuração da sua configuração salva até que ela comece a falhar. A última parte que você adicionou é o que causa isso.

    
por 03.12.2010 / 21:07
0

Certianly nunca ouvi falar de algo parecido com isso, apesar de executar vários sites LAMP de pequeno e médio porte.

Aside from suspecting svn is where something is going wrong

Como seria difícil verificar se o conteúdo de save.php não foi substituído por save.php? Mas isso por si só não explica por que isso ocorre aleatoriamente.

Você farejou o tráfego ao replicar o bug para garantir que não é devido a redirecionamento ou armazenamento em cache?

O que os registros de acesso e erro mostram depois de exibir o conteúdo errado?

C.

    
por 28.06.2010 / 14:15
0

Eu só tenho um conhecimento superficial de mod_rewrite. Independentemente de ter mod_rewrite, eu recomendaria a exclusão de ambos save.php e view.php do SVN, importando-os novamente com commits separados. Estou saindo de algum conhecimento que ganhei, onde as revisões foram corrompidas e movê-las ou excluí-las e reimportá-las corrige o problema. Não é uma solução elegante (proposta), eu sei.

Espero que isso ajude.

Obrigado,
Zachary

    
por 02.09.2010 / 00:06