doGet y doPost en Servlets

Desarrollé una página HTML que envía información a un servlet. En Servlet, estoy usando los métodos doGet() y doPost() :

 public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { String id = req.getParameter("realname"); String password = req.getParameter("mypassword"); } public void doPost(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { String id = req.getParameter("realname"); String password = req.getParameter("mypassword"); } 

En el código de página html que llama al Servlet es:

 
User Name: Password:

Cuando uso method = "get" en el Servlet, obtengo el valor de id y contraseña, sin embargo cuando se usa method = "post" , el id y la contraseña se establecen en null . ¿Por qué no obtengo los valores en este caso?

Otra cosa que me gustaría saber es cómo usar los datos generados o validados por el Servlet. Por ejemplo, si el Servlet que se muestra arriba autentica al usuario, me gustaría imprimir el ID de usuario en mi página HTML. Debería poder enviar la cadena ‘id’ como respuesta y usar esta información en mi página HTML. ¿Es posible?

Introducción

Debes usar doGet() cuando quieras interceptar en solicitudes HTTP GET . Debe usar doPost() cuando quiera interceptar en solicitudes HTTP POST . Eso es todo. No transfiera el uno al otro o viceversa (como en el desafortunado método auto-generado processRequest() Netbeans). Esto no tiene sentido.

OBTENER

Normalmente, las solicitudes HTTP GET son idempotentes . Es decir, obtiene exactamente el mismo resultado cada vez que ejecuta la solicitud (dejando la autorización / autenticación y la naturaleza temporal de la página (resultados de búsqueda, últimas noticias, etc.) fuera de consideración). Podemos hablar sobre una solicitud marcada. Hacer clic en un enlace, hacer clic en un marcador, ingresar URL en bruto en la barra de direcciones del navegador, etcétera activará una solicitud HTTP GET. Si un Servlet está escuchando en la URL en cuestión, se doGet() su método doGet() . Usualmente se usa para preprocesar una solicitud. Es decir, hacer algunas cosas de negocios antes de presentar el resultado HTML de un JSP, como recostackr datos para mostrarlos en una tabla.

 @WebServlet("/products") public class ProductsServlet extends HttpServlet { @EJB private ProductService productService; @Override protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { List products = productService.list(); request.setAttribute("products", products); // Will be available as ${products} in JSP request.getRequestDispatcher("/WEB-INF/products.jsp").forward(request, response); } } 
  
${product.name} detail

Ver / editar los enlaces de detalles como se muestra en la última columna de arriba generalmente son idempotentes.

 @WebServlet("/product") public class ProductServlet extends HttpServlet { @EJB private ProductService productService; @Override protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { Product product = productService.find(request.getParameter("id")); request.setAttribute("product", product); // Will be available as ${product} in JSP request.getRequestDispatcher("/WEB-INF/product.jsp").forward(request, response); } } 
 
ID
${product.id}
Name
${product.name}
Description
${product.description}
Price
${product.price}
Image

ENVIAR

Las solicitudes HTTP POST no son idempotentes. Si el usuario final ha enviado un formulario POST en una URL de antemano, que no ha realizado una redirección, la URL no es necesariamente marcable. Los datos del formulario enviado no se reflejan en la URL. Copiar el URL en una nueva ventana / pestaña del navegador no necesariamente arrojará exactamente el mismo resultado que después del envío del formulario. Tal URL no es marcable. Si un Servlet está escuchando en la URL en cuestión, se doPost() su doPost() . Por lo general, se usa para posprocesar una solicitud. Es decir, recostackr datos de un formulario HTML enviado y hacer algunas cosas de negocios con él (conversión, validación, guardado en BD, etcétera). Finalmente, generalmente el resultado se presenta como HTML desde la página JSP reenviada.

 
${error}

… que se puede usar en combinación con esta pieza de Servlet:

 @WebServlet("/login") public class LoginServlet extends HttpServlet { @EJB private UserService userService; @Override protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String username = request.getParameter("username"); String password = request.getParameter("password"); User user = userService.find(username, password); if (user != null) { request.getSession().setAttribute("user", user); response.sendRedirect("home"); } else { request.setAttribute("error", "Unknown user, please try again"); request.getRequestDispatcher("/login.jsp").forward(request, response); } } } 

Verá, si el User se encuentra en DB (es decir, el nombre de usuario y la contraseña son válidos), el User será puesto en el scope de la sesión (es decir, “conectado”) y el servlet redirigirá a alguna página principal (este ejemplo va a http://example.com/contextname/home ), de lo contrario establecerá un mensaje de error y reenviará la solicitud a la misma página JSP para que el mensaje se muestre con ${error} .

Si es necesario, también puede “ocultar” login.jsp en /WEB-INF/login.jsp para que los usuarios solo puedan acceder a él por el servlet. Esto mantiene la URL limpia http://example.com/contextname/login . Todo lo que necesita hacer es agregar un doGet() al servlet de esta manera:

 protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.getRequestDispatcher("/WEB-INF/login.jsp").forward(request, response); } 

(y actualice la misma línea en doPost() consecuencia)

Dicho esto, no estoy seguro de si solo está jugando y disparando en la oscuridad, pero el código que publicaste no se ve bien (como usar compareTo() lugar de equals() y buscar los compareTo() los parámetros en lugar de solo utilizando getParameter() y el id y la password parecen estar declarados como variables de instancia de servlet, lo cual NO es seguro para la lectura de hilos ). Por lo tanto, recomendaría encarecidamente que aprenda un poco más sobre la API básica de Java SE utilizando los tutoriales de Oracle (consulte el capítulo “Trails Covering the Basics”) y cómo usar JSP / Servlets de la manera correcta utilizando esos tutoriales .

Ver también:

  • Nuestra página wiki servlets
  • Desarrollo web Java EE, ¿dónde empiezo y qué habilidades necesito?
  • El servlet devuelve “HTTP Status 404 El recurso solicitado (/ servlet) no está disponible”
  • Mostrar JDBC ResultSet en HTML en la página JSP usando el patrón MVC y DAO

Actualización : según la actualización de su pregunta (que es bastante importante, no debe eliminar partes de su pregunta original, esto haría que las respuestas carezcan de valor … en lugar de agregar la información en un nuevo bloque), resulta que usted está establecer innecesariamente el tipo de encoding de formulario en multipart/form-data . Esto enviará los parámetros de solicitud en una composición diferente a la application/x-www-form-urlencoded (predeterminada) application/x-www-form-urlencoded que envía los parámetros de solicitud como una cadena de consulta (por ejemplo, name1=value1&name2=value2&name3=value3 ). Solo necesita datos multipart/form-data siempre que tenga un elemento en el formulario para cargar archivos que pueden ser datos que no son de carácter (datos binarios). Este no es el caso en su caso, así que simplemente elimínelo y funcionará como se espera. Si alguna vez necesita cargar archivos, tendrá que configurar el tipo de encoding y analizar el cuerpo de la solicitud usted mismo. Por lo general, utiliza Apache Commons FileUpload allí, pero si ya tiene una nueva API de Servlet 3.0, puede usar las instalaciones HttpServletRequest#getPart() comenzando con HttpServletRequest#getPart() . Ver también esta respuesta para un ejemplo concreto: ¿Cómo subir archivos al servidor usando JSP / Servlet?

Tanto GET como POST son utilizados por el navegador para solicitar un único recurso del servidor. Cada recurso requiere una solicitud GET o POST por separado.

  1. El método GET es comúnmente utilizado por los navegadores (y es el método predeterminado) para recuperar información de los servidores. Al usar el método GET, la tercera sección del paquete de solicitud, que es el cuerpo de la solicitud, permanece vacía.

El método GET se utiliza de una de estas dos maneras: cuando no se especifica ningún método, es cuando usted o el navegador solicita un recurso simple, como una página HTML, una imagen, etc. Cuando se envía un formulario, y usted elige el método = GET en la etiqueta HTML. Si el método GET se usa con un formulario HTML, los datos recostackdos a través del formulario se envían al servidor al agregar un “?” hasta el final de la URL, y luego agregue todos los pares nombre = valor (nombre del campo de formulario html y el valor ingresado en ese campo) separados por un “&” Ejemplo: GET /sultans/shop//form1.jsp?name= Sam% 20Sultan & iceCream = vanilla HTTP / 1.0 encabezado headeroptional opcional < < línea vacía >>>

Los datos del formulario name = value se almacenarán en una variable de entorno llamada QUERY_STRING. Esta variable se enviará a un progtwig de procesamiento (como JSP, servlet de Java, PHP, etc.)

  1. El método POST se usa cuando se crea un formulario HTML y se solicita method = POST como parte de la etiqueta. El método POST permite al cliente enviar datos de formulario al servidor en la sección de cuerpo de solicitud de la solicitud (como se discutió anteriormente). Los datos están codificados y tienen un formato similar al método GET, excepto que los datos se envían al progtwig a través de la entrada estándar.

Ejemplo: POST /sultans/shop//form1.jsp HTTP / 1.0 encabezado headeroptional opcional < < línea vacía >>> name = Sam% 20Sultan & iceCream = vainilla

Al usar el método de publicación, la variable de entorno QUERY_STRING estará vacía. Ventajas / desventajas de GET vs. POST

Ventajas del método GET: Se pueden ingresar parámetros un poco más rápidos a través de un formulario o añadiéndolos después de que la página URL se pueda marcar con sus parámetros

Desventajas del método GET: solo puede enviar 4K de datos. (No debe usarlo cuando use un campo de área de texto) Los parámetros son visibles al final de la URL

Ventajas del método POST: los parámetros no son visibles al final de la URL. (Úselo para datos confidenciales) Puede enviar más de 4K de datos al servidor

Desventajas del método POST: no se puede marcar con sus datos

La implementación del método de HttpServlet.service () del contenedor de servlets se reenviará automáticamente a doGet () o doPost () según sea necesario, por lo que no debería necesitar anular el método de servicio.

¿Podría ser que estás pasando los datos a través de obtener, no publicar?

 
..

Si haces

para tu formulario html, los datos se pasarán usando ‘Get’ de manera predeterminada y por lo tanto puedes capturar esto usando la función doGet en tu código de servlet java. De esta forma, los datos se pasarán bajo el encabezado HTML y, por lo tanto, serán visibles en la URL cuando se envíen. Por otro lado, si desea pasar datos en el cuerpo HTML, utilice la publicación:

y capture estos datos en la función doPost. Esto fue, los datos se pasarán en el cuerpo html y no en el encabezado html, y no verá los datos en la URL después de enviar el formulario.

Ejemplos de mi html:

  
..... .....

Ejemplos de mi código de servlet java:

 protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // TODO Auto-generated method stub PrintWriter out = response.getWriter(); String surname = request.getParameter("txtSurname"); String firstname = request.getParameter("txtForename"); String rqNo = request.getParameter("txtRQ6"); String nhsNo = request.getParameter("txtNHSNo"); String attachment1 = request.getParameter("base64textarea1"); String attachment2 = request.getParameter("base64textarea2"); ......... .........