Jump to content
Gonçalo_ssb

Protecção de Pastas do site

Recommended Posts

Gonçalo_ssb

Bom dia,

Estou na recta final do lançamento de um site e estou a rever as questões relativas à segurança. O que pretendo é que não seja possível que por url se possa aceder Às pastas do site, ou seja, que por exemplo ao escrever http://www.omeusite.pt/images apareça a listagem das imagens presentes na pasta images...

Será possível realizar esta restrição no cpanel e como?

Obrigado.

gferraria.

Share this post


Link to post
Share on other sites
IceBrain

Já agora, podes usar a opção "ErrorDocument 403" para poderes mostrar uma página mais amigável, e possivelmente redirigir o utilizador para a página inicial, ou assim.

Erros "Forbidden 403" são feios :thumbsup:


❝The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.❞- John Carmack on software patents

A list  of command line apps

Share this post


Link to post
Share on other sites
falco
Podes usar a opção IndexOptions do Apache, num ficheiro .htacces.

Os indexes são primariamente configurados no ficheiro de configuração do Apache. O .htaccess é utilizado para fazer gestão descentralizada. Não sabemos qual o caso.

Já agora, podes usar a opção "ErrorDocument 403" para poderes mostrar uma página mais amigável,

Se o site for minimamente bem desenhado e implementado dificilmente aparece um 403, ou um 404...

Share this post


Link to post
Share on other sites
IceBrain

Se o site for minimamente bem desenhado e implementado dificilmente aparece um 403, ou um 404...

Nenhum desenho ou implementação impede um utilizador de colar/cortar apenas parte de uma URL, ou de se enganar a escrevê-la, ou de ela ser "cortada" pelo software do site onde for postada, etc.

Tal como a implementação do P@P não me impede de me enganar e escrever http://www.portugal-a-programar.org/formu em vez de "forum" e obter um 404.

Sim, normalmente não acontecerá, mas não custa nada fazer uma página de erro "limpa" que use o template geral do site e informe o utilizador que a página não existe.

A client called complaining that she couldn’t access the company website. When I get there, this is what she had typed in the URL field: “the company website”.

http://clientsfromhell.net/post/413281458/a-client-called-complaining-that-she-couldnt

Não podemos depender do que achamos razoável que os utilizadores façam...


❝The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.❞- John Carmack on software patents

A list  of command line apps

Share this post


Link to post
Share on other sites
falco

Tal como a implementação do P@P não me impede de me enganar e escrever http://www.portugal-a-programar.org/formu em vez de "forum" e obter um 404.

Se o site for bem programado tens handlers para todos os requests, que primeiro verificam se o url é válido e/ou se corresponde a um url para o qual temos componentes que respondem a esse url. E no caso de não haver nenhum esses handlers costumam ter uma acção (ou várias), que podem realizar. As frameworks de desenvolvimento web modernas, já permitem fazer isto, com muito pouco trabalho.

Share this post


Link to post
Share on other sites
IceBrain

Oh, mas tens 404 na mesma, podes é geri-los na aplicação e não no Apache.

Neste caso, visto que o erro já está a ser tratado pelo Apache (usando o NoIndexing), é óbvio que não há nenhum handler geral a gerir os pedidos, portanto o ErrorDocument é a melhor forma.

E em muitos casos ter um handler que gira tudo é overkill - por exemplo, para servir conteúdos estáticos. Não vejo a utilidade de servir ficheiros CSS ou imagens através de um handler quando é muito mais eficiente deixar o servidor HTTP tratar dos ficheiros (e dos erros).

Neste caso, o ErrorDocument é útil.


❝The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.❞- John Carmack on software patents

A list  of command line apps

Share this post


Link to post
Share on other sites
falco
Oh, mas tens 404 na mesma, podes é geri-los na aplicação e não no Apache.

Não!

Os 404 acontecem quando o servidor não tem nada mais para responder ao request. Neste caso as aplicações web respondem sempre, logo o servidor tem sempre algo mais para responder ao request...

Share this post


Link to post
Share on other sites
IceBrain

Não, o 404 significa que o recurso representado por aquele URL não existe ou não está disponível.

Se tens uma página de erro personalizada, podes mostrá-la na mesma. É o que faz o Google, Sun, Yahoo, Microsoft, etc.

Também podes dar o 404 com um header Location: path para redirigires para outro recurso.

Os 404 acontecem quando o servidor não tem nada mais para responder ao request.

Isso é um 204 No Content, como o próprio indica.

Se o teu site não apresenta um 404 quando o URL pedido não é a representação de nenhum recurso, não estás a cumprir o protocolo HTTP.


❝The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.❞- John Carmack on software patents

A list  of command line apps

Share this post


Link to post
Share on other sites
falco
Não, o 404 significa que o recurso representado por aquele URL não existe ou não está disponível.

Se tens uma framework a dizer ao servidor que existe sempre então vai estar sempre disponível... Por exemplo o mason faz isso com os dhandlers e/ou combinando-os com os autohandlers.

Share this post


Link to post
Share on other sites
IceBrain

Mas não representa um recurso! Um recurso é suposto ter um significado semântico, não é simplesmente uma resposta qualquer.

Do RFC 2396, que especifica as URIs:

A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., "today's weather report for Los Angeles"), and a collection of other resources. Not all resources are network "retrievable"; e.g., human beings, corporations, and bound books in a library can also be considered resources

portugal-a-programar.org/forum representa um "fórum". Que recurso representa "portugal-a-programar.org/formun" ? Nada! Não tem identidade semântica!.

Isto não é uma questão técnica, é óbvio que é possível devolver sempre 200 OK, mas não estás a cumprir os protocolos dos RFC 2616 e 2396, que definem o HTTP e os URLs, respectivamente.

Por exemplo o mason faz isso com os dhandlers e/ou combinando-os com os autohandlers.

E no entanto nos seus próprios manuais dão este exemplo:

    <& header &>
    <b><% $headline %></b><p>
    <% $body %>
    <& footer &>

    <%init>
    my $arg = $m->dhandler_arg;                # get rest of path
    my ($section, $story) = split("/", $arg);  # split out pieces
    my $sth = $DBH->prepare
        (qq{SELECT headline,body FROM news
            WHERE section = ? AND story = ?);
    $sth->execute($section, $story);
    my ($headline, $body) = $sth->fetchrow_array;
    return 404 if !$headline;                  # return "not found" if no such story
    </%init>

http://www.masonhq.com/docs/manual/Devel.html#dhandlers

Repito: A questão não é técnica, é semântica, mas está bem definida nos RFC e em todo o conceito da Web,

E já agora, estás a destruir a possibilidade de automatizar a verificação de links. Se uma URL de um post que já não existe devolve 200 OK na mesma, perde-se a possibilidade de um programa informático identificar links "perdidos".

Numa altura em que a Web Semântica começa a aparecer e em que aumentam os browsers não-HTML (como backends de sites que "pingam" links - ver Facebook & OpenGraph), cumprir com os protocolos que são "machine-readable" parece-me cada vez mais importante.


❝The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.❞- John Carmack on software patents

A list  of command line apps

Share this post


Link to post
Share on other sites
falco
Mas não representa um recurso! Um recurso é suposto ter um significado semântico, não é simplesmente uma resposta qualquer.

Representa pois!

Do ponto de vista dos internals de um servidor um recurso não tem que ser um ficheiro que existe no file-system. Tem é que corresponder a uma acção invocada por um handler do servidor. Quer dhandler, quer o autohandlers são handlers adicionados ao servidor via mod_perl (que usa a API do Apache HTTP Server).

O recurso pode ser um ficheiro ou pode ser um output de uma aplicação executada no servidor. O que o servidor retorna é um ficheiro, como ele o cria é irrelevante.

Não confundas o ponto de vista do cliente, como ponto de vista do servidor e acho que é isso que tas a fazer (pelo menos parece-me).

E no entanto nos seus próprios manuais dão este exemplo:

Esse exemplo é para o caso de quereres retornar mesmo um 404, e por exemplo não executares um controlador qualquer como se tivesse encontrado uma página.

E já agora, estás a destruir a possibilidade de automatizar a verificação de links.

Não estou, não!

Só estou a mudar quem o verifica, estou mesmo a aumentar a granularidade e inteligência da verificação. Ao permitir à aplicação web decidir o que fazer, se executa algum controlador para uma acção que queiras forçar nesse caso, ou se caso não saiba o que fazer, devolver o 404 (como no caso do exemplo que copiaste).

E já agora, estás a destruir a possibilidade de automatizar a verificação de links. Se uma URL de um post que já não existe devolve 200 OK

Mas devolve...

Numa altura em que a Web Semântica começa a aparecer e em que aumentam os browsers não-HTML (como backends de sites que "pingam" links - ver Facebook & OpenGraph), cumprir com os protocolos que são "machine-readable" parece-me cada vez mais importante.

Robots devem respeitar o robots.txt... Um site bem construído tem um ficheiro desses que lhes indica, onde e onde não ir.

Share this post


Link to post
Share on other sites
IceBrain
Representa pois!

Do ponto de vista dos internals de um servidor um recurso não tem que ser um ficheiro que existe no file-system. Tem é que corresponder a uma acção invocada por um handler do servidor. Quer dhandler, quer o autohandlers são handlers adicionados ao servidor via mod_perl (que usa a API do Apache HTTP Server).

O recurso pode ser um ficheiro ou pode ser um output de uma aplicação executada no servidor. O que o servidor retorna é um ficheiro, como ele o cria é irrelevante.

Não confundas o ponto de vista do cliente, como ponto de vista do servidor e acho que é isso que tas a fazer (pelo menos parece-me).

Não, o que o servidor retorna é a representação de um recurso. O conceito de ficheiro não se aplica. E esse recurso tem que ter uma identidade definida. Um significado.

É óbvio que não ter que ser um ficheiro no FS do servidor - e normalmente já não o é. Mas isso não interessa.

Volto ao meu exemplo: quando eu peço http://portugal-a-programar.org/formun, qual é a identidade deste recurso? Que conceito abstracto ou real representa?

Se não representada nada, não se pode devolver um 200 OK. Não estás a cumprir o protocolo.

Esse exemplo é para o caso de quereres retornar mesmo um 404, e por exemplo não executares um controlador qualquer como se tivesse encontrado uma página.

As URIs não encontram páginas, encontram recursos. As páginas são aquilo que devolvem.

E lá está, há casos em que uma aplicação mesmo "bem construída" tem que devolver 404 - porque o recurso não foi encontrado.

Não estou, não!

Só estou a mudar quem o verifica, estou mesmo a aumentar a granularidade e inteligência da verificação. Ao permitir à aplicação web decidir o que fazer, se executa algum controlador para uma acção que queiras forçar nesse caso, ou se caso não saiba o que fazer, devolver o 404 (como no caso do exemplo que copiaste).

For crying out loud, quem é que disse que eu queria tirar à aplicação o poder de decidir? Claro que pode ser a aplicação a decidir!

Aliás eu disse:

Oh, mas tens 404 na mesma, podes é geri-los na aplicação e não no Apache.

E tu negaste!

Mas devolve...

Mas não pode! O post não existe!

Robots devem respeitar o robots.txt... Um site bem construído tem um ficheiro desses que lhes indica, onde e onde não ir.

Sim?

Imagina que tens a URL: http://exemplo.com/post/45 que representa um post num blog. Há pessoas que linkam esse post noutros sites. Depois o blogger decide apagar o post.

Vais acrescentar esse URL ao robots.txt? Não, isso não faz sentido, não é esse o objectivo do robots.txt.

Mas não pode devolver 200, porque o recurso (o post) já não existe. Logo, 404 (ou neste caso, 410) é a única opção válida.


❝The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.❞- John Carmack on software patents

A list  of command line apps

Share this post


Link to post
Share on other sites
falco

Nota: vou utilizar linguagem especifica do mason.

Volto ao meu exemplo: quando eu peço http://portugal-a-programar.org/formun, qual é a identidade deste recurso? Que conceito abstracto ou real representa?

Para mim, como utilizador isso é irrelevante. Só para o servidor é que isso interessa.

Se não representada nada, não se pode devolver um 200 OK. Não estás a cumprir o protocolo.

O que o dhandler e/ou o autohandler, fazem é passar a escolha de representar algo ou não para o programador, em vez de para o servidor.

O programador pode querer alterar estados, sessões, ou cookies, ou invocar algum tipo de acção num back-end quando estes handlers são invocados e só depois passar o controlo de volta para o servidor, dizendo-lhe para responder o 404.

O programador pode também querer que sempre que um recurso não exista, ele seja criado automaticamente (por exemplo acontece algo semelhante com os wiki). Ou passar o controlo para um (ou mais) outro controlador, conforme algum estado, sessão, ou cookie, com com algo mais que ache relevante para a função da aplicação.

Ambas estas acções respeitam o protocolo. Porque o HTTP é um protocolo de comunicação, não é uma norma de aplicações. O que define qual é a resposta a ser dada é o servidor e/ou a aplicação. E desde que hajam controladores a ser invocados pelos handlers, pode um recurso e o que decide isso é o controlador e não o servidor (o servidor só decide quando não há nada para ser invocado).

E lá está, há casos em que uma aplicação mesmo "bem construída" tem que devolver 404 - porque o recurso não foi encontrado.

A não ser que seja criado um handler para criar on-demmand recursos. Para lidar com o pedido.

For crying out loud, quem é que disse que eu queria tirar à aplicação o poder de decidir? Claro que pode ser a aplicação a decidir!

Disseste, e continuas a dizer... Ao dizer que eu não devo gerar dinamicamente um recurso com base num pedido. Mas sim retornar uma mensagem de falha.

Aliás eu disse:

    Oh, mas tens 404 na mesma, podes é geri-los na aplicação e não no Apache.

O 404 só existe se o Apache o chamar internamento, ou se for invocado por uma aplicação que use a API do Apache.

Se usares um dhandler, ou um autohandler, o handler para enviar a resposta do 404 só é chamado se tu o invocares explicitamente. Podes não o fazer. E nesse caso ele não ocorre.

Mas não pode! O post não existe!

Pode ser criado on-demmand...

O autohandler e o dhandler, existem para o programador decidir ser os cria, se quer fazer algo antes de falhar, se simplesmente quer seja o servidor a responder de acordo com o seu comportamento por omissão e/ou configurado de outra forma.

Sim?

Imagina que tens a URL: http://exemplo.com/post/45 que representa um post num blog. Há pessoas que linkam esse post noutros sites. Depois o blogger decide apagar o post.

Vais acrescentar esse URL ao robots.txt? Não, isso não faz sentido, não é esse o objectivo do robots.txt.

Conteúdo que é gerado e gerido dinamicamente não deve ser indexado. O robots.txt deve contribuir para prevenir essa indexação previamente. Se escolheres indexar apesar disso, estás por tua conta e risco. Contudo é simpático deixar alguma informação e isso pode ser feito com um dhandler com um controlador a gerar respostas: que digam de forma adequada o que aconteceu ao conteúdo e/ou eventualmente para indicar também novas formas de obter esse conteúdo.

Agentes que não um browser e que usam a chamada web semântica, devem funcionar de forma correcta, ou seja, recorrendo a feeds RDF, RSS, ou conteúdos gerados em micro-formatos especificamente para esse tipo de agentes, API como as de web-services, etc... Quando não o fazem, estão por sua conta e risco.

Sou no entanto da opinião que, nos tempos em que correm, é no mínimo simpático, para quem usa esses agentes e útil para quem quer distribuir conteúdos/fornecer serviços disponibilizar formas adequadas para que esses agentes possam ser utilizados de forma correcta.

Share this post


Link to post
Share on other sites
IceBrain
Para mim, como utilizador isso é irrelevante. Só para o servidor é que isso interessa.

Não, não é. O protocolo é tão válido para o cliente como para o servidor.

O servidor é que decide se aquilo representa um recurso válido, mas se decidir que sim, esse recurso tem que ter uma identidade semântica válida.

O programador pode querer alterar estados, sessões, ou cookies, ou invocar algum tipo de acção num back-end quando estes handlers são invocados e só depois passar o controlo de volta para o servidor, dizendo-lhe para responder o 404.

Mas a questão não era se a aplicação podia ou não fazer tarefas. O que tu disseste foi "uma aplicação bem construída nunca devolve 404".

Então afinal já devolve?

A não ser que seja criado um handler para criar on-demmand recursos. Para lidar com o pedido.

Os recursos não lidam com pedidos. Os recursos são conceitos semânticos abstractos.

"Módulo login.jsp" não é um recurso. Um recurso é "carro" ou "post". Não são agentes.

Agora, é verdade que se podem criar recursos em resposta a pedidos. Mas nem sempre isso faz sentido, como no caso de um typo na URI. Nesse caso, um 404 é o adequado.

O 404 só existe se o Apache o chamar internamento, ou se for invocado por uma aplicação que use a API do Apache.

Se usares um dhandler, ou um autohandler, o handler para enviar a resposta do 404 só é chamado se tu o invocares explicitamente. Podes não o fazer. E nesse caso ele não ocorre.

Mas deve ser feito caso a URI não represente um conceito semântico.

Pode ser criado on-demmand...

O autohandler e o dhandler, existem para o programador decidir ser os cria, se quer fazer algo antes de falhar, se simplesmente quer seja o servidor a responder de acordo com o seu comportamento por omissão e/ou configurado de outra forma.

Portanto, quando eu, um leitor normal (não autorizado) acedo a um post que não existe, ele vai ser criado? Deve ser excelente para spammers.

Segundo, um GET é uma operação segura, não deve criar recursos. Mesmo que eu esteja autorizado, fazer GET a uma URI de um post não deve criá-lo mesmo que não exista. Se o post não existe, uma aplicação correta deve devolver 404 ou 410.

Conteúdo que é gerado e gerido dinamicamente não deve ser indexado. O robots.txt deve contribuir para prevenir essa indexação previamente. Se escolheres indexar apesar disso, estás por tua conta e risco.

Não estou a falar de crawlers. Estou a falar de pessoas que postam links, e que são posteriormente analisados.

Até podes ser tu próprio a postar um link para uma página tua aqui no fórum.

Contudo é simpático deixar alguma informação e isso pode ser feito com um dhandler com um controlador a gerar respostas: que digam de forma adequada o que aconteceu ao conteúdo e/ou eventualmente para indicar também novas formas de obter esse conteúdo.

Não é "simpático", faz parte do RFC. Não o fazer é desrespeitar o protocolo.


❝The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.❞- John Carmack on software patents

A list  of command line apps

Share this post


Link to post
Share on other sites
falco
Não, não é. O protocolo é tão válido para o cliente como para o servidor.

Falei de utilizador, não de cliente. Não é a mesma coisa.

O servidor é que decide se aquilo representa um recurso válido, mas se decidir que sim, esse recurso tem que ter uma identidade semântica válida.

E nos exemplos que dei tem, porque é criada.

Mas a questão não era se a aplicação podia ou não fazer tarefas. O que tu disseste foi "uma aplicação bem construída nunca devolve 404".

Então afinal já devolve?

Não devolve, porque não deixa que aconteça situações em que seja necessário devolver.

Os recursos não lidam com pedidos. Os recursos são conceitos semânticos abstractos.

"Módulo login.jsp" não é um recurso. Um recurso é "carro" ou "post". Não são agentes.

Podem lidar! Aplicações que usam interfaces como o mod_perl, podem lidar.

Agora, é verdade que se podem criar recursos em resposta a pedidos. Mas nem sempre isso faz sentido, como no caso de um typo na URI. Nesse caso, um 404 é o adequado.

Não necessariamente. Por exemplo no caso de um wiki não é.

Mas deve ser feito caso a URI não represente um conceito semântico.

Não necessariamente! Há mais coisas a considerar, como por exemplo o propósito e a natureza da aplicação em si.

Portanto, quando eu, um leitor normal (não autorizado) acedo a um post que não existe, ele vai ser criado? Deve ser excelente para spammers.

Estás a distorcer... E eu já respondi que nesse caso o que está mal não é a aplicação, mas estares a aceder ao site com o tipo de aplicação errada.

Se queres utilizar um leritor de feeds, por exemplo, deves aceder aos recursos que são disponibilizados para os leitores de feeds. Se tas a utilizar uma outra aplicação que foi feita para ler conteúdos disponibilizados de formas especificas, por exemplo com micro-formatos, então é errado estares a aceder aos conteúdos sem ser das formas que o site disponibiliza para esse tipo de aplicações.

Não estou é a ver o que os spammers têm a ver com isto...

Segundo, um GET é uma operação segura, não deve criar recursos.

Por tanto os wikis não devem existir?

Não estou a falar de crawlers. Estou a falar de pessoas que postam links, e que são posteriormente analisados.

Crawlers, não são os únicos robots, nem as únicas aplicações que devem obedecer ao robots.txt.

Não é "simpático", faz parte do RFC. Não o fazer é desrespeitar o protocolo.

Não, não é!

O que eu disse nem tem nada a ver com o RFC. Está para além disso. Tem a ver com dar conteúdo ao utilizador para que ele tenha mais informação objectiva sobre como obter o conteúdo que pretende e não simplesmente dizer se o recurso existe, ou não.

Share this post


Link to post
Share on other sites
IceBrain
E nos exemplos que dei tem, porque é criada

No exemplo que eu dei, não pode, porque não faz sentido.

Não devolve, porque não deixa que aconteça situações em que seja necessário devolver.

A aplicação controla toda a Web, de forma a assegurar que todos os links são válidos?

Podem lidar! Aplicações que usam interfaces como o mod_perl, podem lidar.

Eu vou repetir: um recurso é um conceito abstracto. Não é um processo, ou um módulo, ou um pedaço de código, ou um ficheiro HTML, ou wtv.

Lá porque há código da aplicação a lidar com o pedido, não significa que um recurso tenha que ser criado.

E se o pedido for um GET, não deve ser criado. Nem se for um POST/PUT e o utilizador não tiver permissões.

Não necessariamente. Por exemplo no caso de um wiki não é.

E no entanto a Wikipedia devolve 404 quando o artigo não existe. Se calhar, é mesmo.

Não necessariamente! Há mais coisas a considerar, como por exemplo o propósito e a natureza da aplicação em si.

Sim, se os devs da aplicação não quiserem usar HTTP, estão há vontade. Mas se quiserem, têm que o fazer.

Estás a distorcer... E eu já respondi que nesse caso o que está mal não é a aplicação, mas estares a aceder ao site com o tipo de aplicação errada.

Mas ninguém diz que a aplicação está mal. O que digo é que caso receba um pedido para um recurso que não existe, deve devolver 404.

Porque é que esse pedido foi criado (tipo de aplicação errada, link desactualizado, wtv) é irrelevante.

Por tanto os wikis não devem existir?

Devem. E devem devolver 404 quando recebem um pedido GET para um artigo que não existe. Como o Wikipedia faz.

Crawlers, não são os únicos robots, nem as únicas aplicações que devem obedecer ao robots.txt.

O objectivo do robots.txt não é listar que páginas não existem. É listar que páginas existem mas não devem ser acedidas por crawlers.

Não, não é!

O que eu disse nem tem nada a ver com o RFC. Está para além disso. Tem a ver com dar conteúdo ao utilizador para que ele tenha mais informação objectiva sobre como obter o conteúdo que pretende e não simplesmente dizer se o recurso existe, ou não.

Podes devolver os conteúdos que quiserem e dar 404 na mesma. Nada no protocolo te impede de devolveres o que quiseres no 404.

Como já disse, 404 não tem nada a ver com o tamanho do conteúdo devolvido.


❝The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.❞- John Carmack on software patents

A list  of command line apps

Share this post


Link to post
Share on other sites
falco
No exemplo que eu dei, não pode, porque não faz sentido.

Os exemplos que tu deste, não têm contexto suficiente...

A aplicação controla toda a Web, de forma a assegurar que todos os links são válidos?

Entraste em modo de desconversar...

Lá porque há código da aplicação a lidar com o pedido, não significa que um recurso tenha que ser criado.

Tem se for esse o objectivo da aplicação, ou se for um requisito da aplicação.

E se o pedido for um GET, não deve ser criado. Nem se for um POST/PUT e o utilizador não tiver permissões.

Deve se for o objectivo e/ou um requisito da aplicação.

Um bom exemplo para um GET é o dos wikis.

E no entanto a Wikipedia devolve 404 quando o artigo não existe. Se calhar, é mesmo.

É verdade! Ele devolve um 404 e uma página cmo a opção para criares o artigo quando fazes o primeiro pedido. Mas depois permite-te (se tiveres permissões) fazer um GET para o mesmo recurso ao qual ele te devolve um 200 (se tiveres permissões) e no entanto o recurso continua a não existir. Não contes só metade da história...

A questão é que o que decide a existência de um recurso, ou não, são os requisitos da aplicação. Se uma aplicação quer responder sempre gerando dinamicamente recursos. Então não faz sentido devolver o 404. Se a aplicação quer mostrar uma determinada página sempre que um recurso não existe (uma página que não seja de erro), então não faz sentido devolver um 404. Tudo depende dos objectivos e requisitos da aplicação.

Sim, se os devs da aplicação não quiserem usar HTTP, estão há vontade. Mas se quiserem, têm que o fazer.

Estás enganado...

Mas ninguém diz que a aplicação está mal. O que digo é que caso receba um pedido para um recurso que não existe, deve devolver 404.

Se o objectivo da aplicação for gerar dinamicamente respostas então não. E o caso dos wikis é um bom exemplo porque eles geram os recursos de forma dinâmica e respondem 200 OK para recursos dos pedidos para recursos que não existem (embora nem todos os façam em todas as situações, fazem-no apenas quando faz sentido do ponto de vista do seu negócio).

Devem. E devem devolver 404 quando recebem um pedido GET para um artigo que não existe. Como o Wikipedia faz.

Então como é que se criava um novo artigo?

O objectivo do robots.txt não é listar que páginas não existem. É listar que páginas existem mas não devem ser acedidas por crawlers.

Estás enganado!

O objectibo do robots.txt vai muito para além dos crawlers, mas sim todo o tipo de robots.

Podes devolver os conteúdos que quiserem e dar 404 na mesma. Nada no protocolo te impede de devolveres o que quiseres no 404.

Aqui tens razão.

Formalmente, tens razão, eu só discordo contigo num aspecto, que não tem nada a ver com o standard, que é o de muitas aplicações gerarem recursos elas próprias e nesse caso, não faz sentido retornar um 404 (pelo menos na situação em que ele vai ser gerado).

Share this post


Link to post
Share on other sites
IceBrain
É verdade! Ele devolve um 404 e uma página cmo a opção para criares o artigo quando fazes o primeiro pedido. Mas depois permite-te (se tiveres permissões) fazer um GET para o mesmo recurso ao qual ele te devolve um 200 (se tiveres permissões) e no entanto o recurso continua a não existir. Não contes só metade da história...

Errado! Se eu continuar a fazer GETs, continuo a receber 404. Nunca na Wikipedia recebo outra coisa senão 404 se fizer GET a um artigo que não existe. Nunca.

Posso criar o artigo (usando POST ou PUT, nunca GET), mas aí o recurso passou a existir, por isso é que não recebo 404.

A questão é que o que decide a existência de um recurso, ou não, são os requisitos da aplicação. Se uma aplicação quer responder sempre gerando dinamicamente recursos.

Mas os casos válidos em que recursos são criados dinamicamente quando há um pedido GET são muitíssimo raros. Normalmente, é uma utilização errada do verbo HTTP, pois está a ter efeitos secundários numa operação que é suposto ser segura.

Quote da w3c:

In the same section, HTTP/1.1 states, the convention is that GET is used for safe interactions and SHOULD NOT have the significance of taking an action other than retrieval. Indeed, if you use GET for interactions with side-effects, your make your system insecure. (...) Users accept obligations through other mechanisms than requests to follow a link. Per the HTTP/1.1 specification, designers should use HTTP POST for those interactions.

http://www.w3.org/2001/tag/doc/whenToUseGet.html#safe

Como vês, não deves criar recursos quando há um GET. É uma operação segura, logo não deve ter efeitos secundários, como a criação de recursos.

E já agora, repito: um recurso não é um processo, ou um pedaço de HTML. É um conceito como "post" ou "carro".

Então não faz sentido devolver o 404. Se a aplicação quer mostrar uma determinada página sempre que um recurso não existe (uma página que não seja de erro), então não faz sentido devolver um 404. Tudo depende dos objectivos e requisitos da aplicação.

Um GET está a pedir a representação de um recurso que não existe; a única resposta possível é 404. Podes devolver também conteúdo HTML simpático para o utilizador saber o que pode fazer nesse caso (como a Wikipedia faz), mas não deixas de ter que devolver 404.

Se o objectivo da aplicação for gerar dinamicamente respostas então não. E o caso dos wikis é um bom exemplo porque eles geram os recursos de forma dinâmica e respondem 200 OK para recursos dos pedidos para recursos que não existem (embora nem todos os façam em todas as situações, fazem-no apenas quando faz sentido do ponto de vista do seu negócio).

Mostra-me um software de Wiki que não devolva 404 quando há um pedido GET a um artigo que não existe. Um exemplo, no mínimo.

Já te mostrei que a Wikipedia devolve 404 nesse caso. Sempre.

Então como é que se criava um novo artigo?

Como um POST ou PUT, que é para isso que esses verbos servem. GET é uma operação segura, não deve ter efeitos secundários.

Estás enganado!

O objectibo do robots.txt vai muito para além dos crawlers, mas sim todo o tipo de robots.

Isso é a parte menos importante da minha frase, mas eu reformulo:

"objectivo do robots.txt não é listar que páginas não existem. É listar que páginas existem mas não devem ser acedidas".


❝The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.❞- John Carmack on software patents

A list  of command line apps

Share this post


Link to post
Share on other sites
falco
Mas os casos válidos em que recursos são criados dinamicamente quando há um pedido GET são muitíssimo raros. Normalmente, é uma utilização errada do verbo HTTP, pois está a ter efeitos secundários numa operação que é suposto ser segura.

Ok, admites que existem!

Como vês, não deves criar recursos quando há um GET. É uma operação segura, logo não deve ter efeitos secundários, como a criação de recursos.

Há casos em que queres ter esses efeitos secundários. Claro que deves considerar primeiro se não deves utilizar POST.

Mostra-me um software de Wiki que não devolva 404 quando há um pedido GET a um artigo que não existe. Um exemplo, no mínimo.

Já te mostrei que a Wikipedia devolve 404 nesse caso. Sempre.

O TRAC!

O TRAC utiliza uma solução diferente do MediaWiki. O MediaWiki, com a resposta ao qual te responde o 404 envia um formulário para criares a nova página e com isso faz um POST. Mas o TRAC não faz isso. O TRAC depois de te ter respondido pela primeira vez o 404 acompanhado por uma página a dizer que o recurso não existe, nessa mesma página ele inclui o seguinte:

      </div>
          <div class="buttons">
              <form method="get" action="/demo-0.11/wiki/TeSt" id="modifypage">

                <div>
                  <input type="hidden" name="action" value="edit" />
                      <input type="submit" value="Create this page" />
                </div>
              </form>
          </div>

"objectivo do robots.txt não é listar que páginas não existem. É listar que páginas existem mas não devem ser acedidas".

Se forem recursos gerados de forma dinâmica é como se existissem...

Share this post


Link to post
Share on other sites
IceBrain
Ok, admites que existem!

*sigh* eu nunca disse que não existiam. Esta conversa começou porque TU disseste que "numa aplicação bem construída dificilmente aparece um 404. Eu estou a tentar mostrar que isso não é verdade, e que 404 é uma resposta válida e correcta em muitíssimos casos.

Há casos em que queres ter esses efeitos secundários. Claro que deves considerar primeiro se não deves utilizar POST.

Em princípio não deve. Pode haver excepções, mas não conheço nenhum caso.

O TRAC!

O TRAC utiliza uma solução diferente do MediaWiki. O MediaWiki, com a resposta ao qual te responde o 404 envia um formulário para criares a nova página e com isso faz um POST. Mas o TRAC não faz isso. O TRAC depois de te ter respondido pela primeira vez o 404 acompanhado por uma página a dizer que o recurso não existe, nessa mesma página ele inclui o seguinte:

Errado.

Primeiro, devolve 404.

Segundo, experimenta carregar no botão, e depois voltar a abrir a página. Como vês, volta a devolver 404. Porquê? Porque o GET não criou o recurso, este só é criado quando a página é guardada, com um POST.

Ou seja, o TRAC funciona exactamente como o MediaWiki, só que em vez de um link, usa um botão na UI.

Se forem recursos gerados de forma dinâmica é como se existissem...

Então quando ele é criado vais editar o robots.txt para passar a ser permitido fazer crawling? Ou ficas com o site inacessível aos motores de pesquisa?


❝The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.❞- John Carmack on software patents

A list  of command line apps

Share this post


Link to post
Share on other sites
falco
*sigh* eu nunca disse que não existiam.

Então entendi-te mal.

Esta conversa começou porque TU disseste que "numa aplicação bem construída dificilmente aparece um 404. Eu estou a tentar mostrar que isso não é verdade, e que 404 é uma resposta válida e correcta em muitíssimos casos.

Claro que é válida. Nem eu disse que não é.

Quanto ao resto, tens razão, uma aplicação bem construída pode perfeitamente retornar um 404.

Errado.

Primeiro, devolve 404.

Devolve o 404 quando tentas aceder ao recurso da primeira vez.

Segundo, experimenta carregar no botão, e depois voltar a abrir a página. Como vês, volta a devolver 404. Porquê? Porque o GET não criou o recurso, este só é criado quando a página é guardada, com um POST.

Não devolve não...

GET /demo-0.11/wiki/TestLink?action=edit HTTP/1.1

Host: trac.edgewall.org

User-Agent: Mozilla/5.0 (X11; U; Linux i686; pt-PT; rv:1.9.2.12) Gecko/20101027 Ubuntu/10.04 (lucid) Firefox/3.6.12

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: pt-pt,en;q=0.8,pt;q=0.5,en-us;q=0.3

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 115

Connection: keep-alive

Referer: http://trac.edgewall.org/demo-0.11/wiki/TestLink

Cookie: trac_session=4a7c38b11de3481587d08e17; trac_form_token=97e468cc53f74fb7c29ca5c2



HTTP/1.1 200 OK

Cache-control: must-revalidate

Content-Type: text/html;charset=utf-8

Content-Length: 6867

Date: Wed, 17 Nov 2010 12:51:37 GMT

Server: lighttpd/1.4.19



<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

Ou seja, o TRAC funciona exactamente como o MediaWiki, só que em vez de um link, usa um botão na UI.

Não, não funciona...

Para a próxima testa antes...

Share this post


Link to post
Share on other sites
IceBrain

Não devolve não...

GET /demo-0.11/wiki/TestLink?action=edit HTTP/1.1

Host: trac.edgewall.org

User-Agent: Mozilla/5.0 (X11; U; Linux i686; pt-PT; rv:1.9.2.12) Gecko/20101027 Ubuntu/10.04 (lucid) Firefox/3.6.12

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: pt-pt,en;q=0.8,pt;q=0.5,en-us;q=0.3

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 115

Connection: keep-alive

Referer: http://trac.edgewall.org/demo-0.11/wiki/TestLink

Cookie: trac_session=4a7c38b11de3481587d08e17; trac_form_token=97e468cc53f74fb7c29ca5c2



HTTP/1.1 200 OK

Cache-control: must-revalidate

Content-Type: text/html;charset=utf-8

Content-Length: 6867

Date: Wed, 17 Nov 2010 12:51:37 GMT

Server: lighttpd/1.4.19



<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

Não, não funciona...

Para a próxima testa antes...

Tens razão, mas não é o botão que cria o recurso - eles devolvem sempre 200, mesmo que não tenha carregado no botão. Ou seja, o recurso não é realmente criado (continua a dizer "The page %s does not exist") e no entanto devolve 200. Isso é um erro.

Aliás, se fizeres o mesmo com um Ticket que não exista, isso já devolve 404. Inconsistências ftw.

Já agora, se o recurso for mesmo criado dinamicamente (o que não é o caso aqui), 200 OK também está errado: deve-se usar 201 Created.

The request has been fulfilled and resulted in a new resource being created.

❝The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.❞- John Carmack on software patents

A list  of command line apps

Share this post


Link to post
Share on other sites
falco
Tens razão, mas não é o botão que cria o recurso - eles devolvem sempre 200, mesmo que não tenha carregado no botão. Ou seja, o recurso não é realmente criado (continua a dizer "The page %s does not exist") e no entanto devolve 200. Isso é um erro.

Se não carregares no botão o recurso não é criado e como tal continua a devolver o 404... Não estou a ver como viste isso do 200 com a mensagem a dizer que a página não existe, porque eu não vejo.

Só devolve 200 caso carregues no botão que despoleta o GET para criar o recurso...

Já agora, se o recurso for mesmo criado dinamicamente (o que não é o caso aqui), 200 OK também está errado: deve-se usar 201 Created.

Não sei se o 201 deveria aparecer apenas quando se faz a submissão do formulário da página criada... Pois só nessa altura é que se termina a criação do recurso.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.