Jump to content
Gonçalo_ssb

Protecção de Pastas do site

Recommended Posts

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
IceBrain

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...

A mim a wiki do próprio TRAC devolve, mas esquece o que eu disse. Vamos rever:
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

Não. A MediaWiki devolve uma página com um link para o formulário. Exactamente como TRAC, só que a UI é diferente.

E esse link (no mediawiki) ou botão (no TRAC) não criam realmente o recurso; se carregares no botão e voltares à página, ele continua a dizer que ela não existe.

Porquê? Porque o recurso só é criado quando há um POST do formulário.

A página do formulário devolve 200 porque aí o recurso não é a "página XPTO", mas o "editor de páginas". São recursos diferentes.

As I said, recurso não existe, deve-se devolver 404. GET não deve ser usado para criar recursos.

Nem a MediaWiki nem o TRAC quebram estas regras.

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.

Certo.

❝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. A MediaWiki devolve uma página com um link para o formulário. Exactamente como TRAC, só que a UI é diferente.

Não, não é a mesma coisa. O TRAC devolve um formulário em que a única coisa que tem é o botão que faz um GET para uma página onde há um formulário para criar uma página no wiki. O MediaWiki, devolve logo todo o formulário onde é criada a nova página do wiki. No TRAC para criar uma nova página há dois GET e um POST, no MediaWiki é um GET e um POST. Logo não é a mesma coisa.

E esse link (no mediawiki) ou botão (no TRAC) não criam realmente o recurso; se carregares no botão e voltares à página, ele continua a dizer que ela não existe.

No MediaWiki não existe o botão que inicia o processo de criação da página do wiki, o formulário para criação da página de wiki vem logo quando a resposta ao primeiro GET (aquele que tem o 404).

No TRAC (como eu já tinha dito), o processo de criação do recurso é iniciado quando se carrega no botão de criar a nova página, mas só é terminado quando é submetido o wikimarkup, ou seja, quando é feito o POST (terceiro passo).

3 passos e 2 passos não são a mesma coisa, neste caso.

A página do formulário devolve 200 porque aí o recurso não é a "página XPTO", mas o "editor de páginas". São recursos diferentes.

Se fosse o recurso editor de páginas, então estou convencido que a resposta teria que ser outra que não o 200, e talvez tivesse que por exemplo haver um redireccionamento.

A minha opinião é que o recurso que corresponde à página pedida passou a existir de forma temporária e que só é criado definitivamente quando é feito o POST (e daí deveria de facto receber um 201, que por acaso nem verifiquei se recebia). Mas não considero a tua perspectiva errada, acho que é apenas uma forma válida e diferente de ver a mesma coisa.

E já agora o tal editor de páginas é um bom exemplo de um dos handlers que referi anteriormente.

Share this post


Link to post
Share on other sites
IceBrain
Não, não é a mesma coisa. O TRAC devolve um formulário em que a única coisa que tem é o botão que faz um GET para uma página onde há um formulário para criar uma página no wiki. O MediaWiki, devolve logo todo o formulário onde é criada a nova página do wiki. No TRAC para criar uma nova página há dois GET e um POST, no MediaWiki é um GET e um POST. Logo não é a mesma coisa.

Não. A MediaWiki devolve um link para o formulário.

http://en.wikipedia.org/wiki/Naoexiste ← onde está o formulário? Só se fizeres um segundo GET, carregando no link "Start the Naoexiste article".

Exactamente como o TRAC, com uma UI diferente.

No MediaWiki não existe o botão que inicia o processo de criação da página do wiki, o formulário para criação da página de wiki vem logo quando a resposta ao primeiro GET (aquele que tem o 404).

No TRAC (como eu já tinha dito), o processo de criação do recurso é iniciado quando se carrega no botão de criar a nova página, mas só é terminado quando é submetido o wikimarkup, ou seja, quando é feito o POST (terceiro passo).

3 passos e 2 passos não são a mesma coisa, neste caso.

Ver acima.

Se fosse o recurso editor de páginas, então estou convencido que a resposta teria que ser outra que não o 200, e talvez tivesse que por exemplo haver um redireccionamento.

Não, a página do link errado não existe, logo devolve 404. Quando carregas no botão, pedes um recurso diferente, que é o editor. Esse existe, logo devolve 200.

A minha opinião é que o recurso que corresponde à página pedida passou a existir de forma temporária e que só é criado definitivamente quando é feito o POST (e daí deveria de facto receber um 201, que por acaso nem verifiquei se recebia). Mas não considero a tua perspectiva errada, acho que é apenas uma forma válida e diferente de ver a mesma coisa.

Mas se existe depois de carregares no botão mas antes do POST, porque é que continua a dizer que não existe? Poderia existir, mas na realidade o TRAC diz que não. E bem, visto que o pedido GET do botão nem sequer é à página, é ao recurso "editor".

E já agora o tal editor de páginas é um bom exemplo de um dos handlers que referi anteriormente.

O que não implica que não se devolva 404, com ou sem handlers.


❝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. A MediaWiki devolve um link para o formulário.

http://en.wikipedia.org/wiki/Naoexiste ← onde está o formulário? Só se fizeres um segundo GET, carregando no link "Start the Naoexiste article".

Exactamente como o TRAC, com uma UI diferente.

Tens razão, devo ter baralhado tabs, ou coisa assim.

Não, a página do link errado não existe, logo devolve 404. Quando carregas no botão, pedes um recurso diferente, que é o editor. Esse existe, logo devolve 200.

Tens razão!

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.