2012-09-14 27 views
10

A veces no estoy seguro de cómo usar webapp2.redirect.webapp2 redirigir explicó

¿Hay algún momento en el que debería utilizar self.redirect("/blah") en lugar de return self.redirect("/blah")

Aquí es mi entendimiento/conjetura de la línea de tiempo: (a veces estoy confundido acerca de si el objeto respuesta hace algo o si webapp2 lo hace)

  1. visito a mi www.mysite.com/name/robert página web multiproceso, cromo envía un GET solicitud (permite asumir esta solicitud es un archivo de texto)
  2. webapp2 agarra este "archivo de texto" y lo convierte en un webapp2.Request. webapp2 también hace una nueva versión de webapp2.Response.
  3. de alguna manera la url de solicitud se le da al enrutador para la coincidencia (ya sea por webapp2 o por la respuesta). Un RequestHandler apropiado es instanciado. Se llama al método get() de RequestHandler con argumentos apropiados.
  4. durante todo este tiempo, solo ha habido una solicitud y una respuesta .
  5. el método get() llama a response.out.write ("hello world") agregando "hello world" al cuerpo de respuesta?
  6. el método get() llama a self.redirect ('/ foo')
  7. cosas que pasan
  8. el método get() llama a self.out.write ("adiós mundo")
  9. la respuesta se envía al cliente que contiene hola mundo, lo que la comida añade, adiós mundo

ejemplo de la función inicial get:

def get(): 
    self.write('hello world') 
    self.redirect('/foo') 
    self.write('bye world') 

¿Qué ocurre "cosas"? Supongo que el enrutador encuentra/foo/'RequestHandler'. Qué modificaciones se hacen a la Solicitud y Respuesta antes de que el método requestHandlers get() de foo se llame. ¿La solicitud se elimina y se reemplaza por una nueva solicitud GET? ¿La respuesta se elimina y se reemplaza por una nueva? ¿Qué contexto queda presente en el controlador de solicitud inicial? ¿la ejecución del código retorna al método de obtención de manejadores de solicitud inicial y si es así, se restaura el contexto que pudo haber existido?

Lo siento si esto es un poco de un bocado, lo he intentado explicar lo que quiero saber :)

Quizás hubiera sido más fácil pedir algunos casos de uso (y no hacer hacer) de utilizando redirigir en su lugar.

Respuesta

10

El método de redireccionamiento es realmente solo una pelusa útil para configurar el estado de la respuesta y el encabezado Location de la respuesta. Nada sucede realmente hasta que la respuesta se envía al cliente que sigue la redirección. Debería devolver el resultado de la redirección de llamadas simplemente para evitar que se ejecute más código si hubo más después del redireccionamiento que no deseaba ejecutar.

La fuente es bastante fácil de leer .. http://webapp2.readthedocs.io/en/latest/_modules/webapp2.html#redirect

+0

lo tanto, el cliente obtiene 302 y sigue la redirección. Eso parece ineficiente (requiere dos solicitudes en lugar de una).Si todos son redirigidos a/login dicen, hubiera pensado que la respuesta devolvería el formulario de inicio de sesión y diría que se redirigió todo en una respuesta, en lugar de dos. –

+1

solo para confirmar, el método foos get() no se llama hasta que el navegador del cliente sigue el redireccionamiento con una nueva solicitud al nuevo encabezado de ubicación de respuestas, lo que significa que el método foos get podría llamarse incluso en un servidor diferente. –

+1

Si desea un redireccionamiento interno, puede llamar a otro método de manejo desde su código, por ejemplo, actualizaré algo en un controlador de envío y devolveré self.get() como respuesta. El problema es que estás devolviendo el contenido de un recurso diferente al solicitado por el servidor. Si eso está bien para la situación, entonces, está bien. Si haces un redireccionamiento, entonces el navegador (o araña) sabe lo que está obteniendo. En cuanto a redirigir Y proporcionar la nueva respuesta, los navegadores bien no funcionan de esa manera. para confirmar: sí, y perdería "hello world" y "bye world" en el éter (para un usuario de navegador) – lecstor