Fernando, Me surgio la misma duda con los logs del IIS, pense que al no validar la pagina devolveria algun otro codigo que 200. Puede que el IIS devuelva 200 ya que la pagina en si, fisicamente, existe con ese nombre, y el problema surge en el ciclo de vida de la aplicacion (en alguno de sus pasos intermedios, en el ValidateRequest? ahi ya me pierdo). Con respecto al HttpModule, si, en teoria se podria realizar toda la logica ahi, pero estructuralmente me parecio mejor que la logica siguiera en la pagina, si bien puede que no sea lo mas performante, el dia de mañana (.NET 3) las cookieless sessions puede que se comporte de manera que estos Modules no sean necesarios. Al ser una aplicacion la cual su uso es esporadico, no me interesa que sea muy performante, prefiero que el Module quede como un "puente" que se pueda sacar cuando sea necesario :) Otra cosa es que la pagina se utiliza en 2 servicios de pago. Uno de ellos envia la informacion mediante un POST normal, la otra mediante el HttpWebRequest (que es con la que surgio el problema). No puedo eliminar la pagina porque el primer servicio de pago exige que haga un Response.Write de un codigo en la pagina para que ellos lo reciban. Ah, nota al margen, el problema de los cookieless sessions tambien se da con POSTs externos normales (desde formularios). La solucion esta en un link en uno de los mails anteriores :) Saludos, Matias
From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: [puntonet] HttpWebRequest(Solucion)Date: Thu, 22 Mar 2007 14:22:48 -0300 Hola Matías. Me alegro que esté funcionando, pero ahora es mi turno de tener algunas dudas. Según lo que describís, el problema es provocado por el uso de cookieless sessions, y tiene sentido, ya que cuando el POST se realiza a la url original, el pipeline aborta y el cliente recibe un redirect a una url que contiene el ID de sesión, por lo tanto el handler de la página nunca llega a ser instanciado en este primer intercambio. Pero la parte que no entiendo es que en ese caso los logs de IIS deberían mostrar un código de estado 302 y no 200. La otra cosa que se me ocurre, y esto tomalo con pinzas ya que todavía no tuve tiempo de analizar bien la solución, es que si ya estás leyendo el form en el HttpModule, ¿no sería más sencillo hacer el procesamiento que originalmente hacía la página aquí mismo y evitar el nuevo HttpWebRequest? Me imagino que como del otro lado no hay un ser humano, no debería existir necesidad de generar HTML en la respuesta - no creo que el servicio de pagos espere otra cosa que un 200 para determinar si el POST tuvo éxito. Saludos, Fernando Tubio ----- Original Message ----- From: Matias Q To: [email protected] Sent: Wednesday, March 21, 2007 1:02 PM Subject: [puntonet] HttpWebRequest(Solucion) Aprovecho y ya que descubri la solucion al problema, la posteo por si alguna vez le sirve a alguien. Contexto: Aplicacion Web con Cookieless SessionsSintoma: No valida ni recibe POSTs hechos a traves de HttpWebRequests externos Solucion:Agregar un HttpModule al webconfig que contenga el siguiente Handler: public void Init (HttpApplication application){ application.EndRequest += new EventHandler(this.Application_EndRequest); }//Basicamente, cuando se trata de la pagina (Confirmacion.aspx en mi caso) que recibe los POSTs, toma la informacion y hace un HttpWebRequest a si mismo//pero la direccion a la cual lo hace, es modificada agregando el token de session//La comparacion entre la RawUrl y CurrentExecutionFilePath es para evitar que se genere un ciclo infinito//ya que la RawUrl es igual a la CurrentExecutionFilePath cuando se recibe el POST externo//pero luego del auto-post, RawUrl contiene el token de session y CurrentExecutionFilePath no, y se corta el cicloprivate void Application_EndRequest(Object source, EventArgs e) { HttpRequest req = HttpContext.Current.Request; HttpResponse res = HttpContext.Current.Response; string currentExecPath = req.CurrentExecutionFilePath.ToUpper(); if(currentExecPath.Contains("CONFIRMACION.ASPX") && req.RawUrl == req.CurrentExecutionFilePath) { WebRequestRedirection(req, res); } }private void WebRequestRedirection(HttpRequest req, HttpResponse res) { System.Net.HttpWebRequest request = (System.Net.HttpWebRequest)System.Net.WebRequest.Create("http://"; + req.Url.Authority + res.ApplyAppPathModifier(req.Url.PathAndQuery)); request.ContentType = "application/x-www-form-urlencoded"; request.Method = "POST"; request.Accept = "text/*"; request.AllowAutoRedirect = true; UTF8Encoding Encoding = new UTF8Encoding(); StringBuilder strValues = new StringBuilder(); foreach (object obj in req.Form) { strValues.Append(string.Format("{0}={1}&", (string)obj, req.Form[(string)obj])); } strValues.Remove(strValues.Length - 1, 1); byte[] postBytes = Encoding.GetBytes(strValues.ToString()); request.ContentLength = postBytes.Length; Stream requestStream = request.GetRequestStream(); requestStream.Write(postBytes, 0, postBytes.Length); requestStream.Close(); } Espero le sirva a alguien a quien se le presente el mismo inconveniente en algun punto. Saludos y gracias a todos por sus comentarios y respuestas Matias From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: [puntonet] HttpWebRequestDate: Wed, 21 Mar 2007 14:38:39 +0000 Gracias inmensamente por la informacion sobre el Fiddler Fernando! Efectivamente, tu modelo del problema es correcto, eso es exactamente lo que pasa. Hay algo que obvié decir y que aparentemente, despues de dos dias de probar, puede ser la raiz del problema. Cookieless Sessions.Aparentemente, debuggeando los diferentes eventos, (supongamos una pagina llamada prueba.aspx), cuando se navega un sitio con Cookieless Sessions, le agrega a la URL algo asi: http://sitio/(Sff345gdfgdsadfs34324)/prueba.aspx. El problema al parecer es que el HttpWebRequest hace el POST a http://sitio/prueba.aspx y este tipo de direccion, si bien es aceptada por el IIS y por la aplicacion, en el punto de validacion de la misma, no lo hace ya que no contiene el token de session. Es por eso que para recibir POST de formularios normales, hay un fix que lo que hace es, en el Application_EndRequest, toma todos los items del Request.Form y reemplaza el Response a enviar al cliente por otro formulario que con los mismos campos y valores pero cuyo ACTION tiene la URL modificada para que sea aceptada (le incluye el token). O sea, el problema al final radicaba en que la aplicacion usaba Cookieless Sessions, era por eso que si bien el Request llegaba, la pagina nunca cargaba. Ahora, el fix que anda dando vueltas es solo para POST de formularios, no soluciona el problema cuando es un HttpWebRequest (porque no hay cliente navegando la pagina como para que la modificacion del Response tome efecto). Para Referencia, y por si le pasa a alguien mas: http://www.developer.com/net/asp/article.php/2216431 El reto ahora va a ser encontrar una solucion que funcione tambien con HttpWebRequests... tengo un don para encontrarme con este tipo de bugs... :P Gracias por todo Matias From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: [puntonet] HttpWebRequestDate: Wed, 21 Mar 2007 09:17:31 -0300 Para estar seguro de haber entendido bien el problema. Cuando mencionás que Fiddler solo detecta el request a la página del "servicio de pago", me imagino que te estás refiriendo a acceder desde tu máquina a la página en tu sitio (Server A) que inicia la operación. Esta página responde con un redirect a un servidor externo (Server B) que pertenece a tu proveedor de servicio de pagos y sobre el cual no tenés ningún control. El servidor externo (Server B) responde entonces con una página donde el cliente ingresa la información necesaria para la transacción y hace un submit. El servidor (Server B) entonces hace un redirect nuevamente a una página en tu sitio (Server A). Todo este intercambio queda registrado en Fiddler ya que ocurre siempre entre tu navegador y los servidores A y B. El Server B, una vez finalizada la transacción, además de redirigir al cliente de regreso al Server A, a su vez hace un request propio, en forma de POST, a otra página en el Server A. Este es el request que tiene problemas. ¿Correcto? El motivo por el cual este último intercambio no queda registrado en Fiddler es que el intercambio ocurre entre los dos servidores, y no involucra al cliente. En realidad hay una forma de capturar también este tipo de tráfico con Fiddler si se lo configura como reverse proxy, aunque es un tanto engorrosa. En el menú de Tools / Fiddler Options... es necesario seleccionar 'Allow remote clients to connect'. Esto permite capturar solicitudes provenientes de clientes externos. El problema es que Fiddler por default escucha en el puerto 8888, mientras que el servidor web probablemente escuche en el puerto 80. Por lo tanto es necesario modificar las reglas de Fiddler para redireccionar el tráfico al puerto apropiado. En el menú 'Rules / Customize rules...' es necesario agregar la siguiente línea al evento OnBeforeRequest: ... static function OnBeforeRequest(oSession:Fiddler.Session) {... // Modificar para reverse proxy, sustituir el nombre correcto if (oSession.host.toLowerCase() == "nombredelservidor:8888") oSession.host = "nombredelservidor:80"; ... } ... Ya que el tráfico es externo, también es necesario abrir el(los) firewall(s), para permitir acceso al puerto 8888 en el servidor. Finalmente, es necesario cambiar el destino del request al nuevo puerto. Así que si antes el servicio de pagos hacía un request a http://serverA/TuPagina.aspx, ahora debe hacerlo a http://serverA:8888/TuPagina.aspx. Como alternativa, si no resulta factible cambiar el puerto al cual hace la solicitud el servidor remoto, se podría configurar Fiddler para que escuche en el puerto 80 y cambiar el servidor local para que atienda en un puerto diferente. Como verás, usar Fiddler para este propósito no es tan simple así que hay que ver si se justifican todas estas maniobras. Probablemente sea más simple usar Network Monitor o Ethereal en estos casos. Otra cosa. ¿Llamando a la página que no funciona directamente desde tu navegador, ejecuta el código de la página? O también, ¿si creás un programita que simplemente haga el HttpWebRequest con el código que enviaste anteriormente, cual es el resultado de la solicitud? Saludos, Fernando Tubio ----- Original Message ----- From: Matias Q To: [email protected] Sent: Tuesday, March 20, 2007 8:34 PM Subject: [puntonet] HttpWebRequest Gracias Fernando, mañana cuando llegue a la oficina pruebo el handler en ese evento. No hay ningun tipo de procesamiento del cache, es decir, es el peor caso de todos, porque es una simple pagina tratando de recibir el Request.InputStream, no tiene ningun pre-procesamiento en ningun evento :( Probe con el Fiddler y partiendo de que tengo 2 paginas (la del Servicio de Pago) y la mia, el Fiddler solo detecta el request de la pagina del Servicio de Pago, luego de que ella hace el POST, el Fiddler en ningun momento detecta nada relacionado con mi pagina (aun cuando el IIS lo loguea y pasa por el Application_BeginRequest y EndRequest). Alguno otro para recomendar? Gracias por toda la ayuda brindada Matias From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: [puntonet] HttpWebRequestDate: Tue, 20 Mar 2007 19:23:25 -0300 (Reenvío el mensaje que salió originalmente hace tres horas pero parece que se perdió en el camino. Seguro que apenas llegue este aparece el otro.) Si es necesario, agregá un handler para PreRequestHandlerExecute en Global.asax y poné un breakpoint allí. Si nunca se detiene en el handler esto significa que el pipeline se está abortando antes de ejecutar el handler de la página, probablemente debido a algún HttpModule que se encuentre configurado. Generalmente lo usual es algo relacionado a la autorización o autenticación, pero el código 200 parece indicar que no es así. Otra posibilidad es que la página se esté resolviendo desde el cache, aunque para un POST parece dudoso. ¿Estás haciendo alguna cosa 'rara' con el cache? La otra cosa que podrías hacer es colgar algún sniffer y ver que es lo que está devolviendo la solicitud realmente. Esto probablemente te indique cual es el problema. Saludos, Fernando Tubio ----- Original Message ----- From: Matias Q To: [email protected] Sent: Tuesday, March 20, 2007 3:39 PM Subject: [puntonet] HttpWebRequest Ok, debuggeando el Application_BeginRequest y Application_EndRequest, cuando se refiere a mi bendita pagina de recepcion de datos, veo que el objeto Request y su InputStream sí contiene los datos recibidos del POST, asi que aproveche a parsearlos y efectivamente los lee sin problemas... Ahora la pregunta es.... por qué los puede leer en el Application_EndRequest pero NUNCA ejecuta el codigo C# de la pagina? Es decir, si el Request llega y es leido por la Aplicacion, se pierde en algun punto del eter informatico? :P Hay dias en que me gustaría ser pescador y que lo unico que se puede complicar es si se me pierden las lombrices para la carnada :P Matias From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: [puntonet] HttpWebRequestDate: Tue, 20 Mar 2007 14:47:21 -0300 ¿La página no estará protegida por algún tipo de autenticación? En ese caso podría estar rebotando en el AuthenticateRequest y nunca llegaría a ejecutar el handler de la página, aunque sí ejecutaría EndRequest. ¿En los logs de IIS, el código de estado devuelto para esta solicitud es 200 o algo diferente? Enganchando un debugger al proceso y poniendo un breakpoint en Application_BeginRequest podrías seguir el flujo de la solicitud en el pipeline. Saludos, Fernando Tubio ----- Original Message ----- From: Matias Q To: [email protected] Sent: Tuesday, March 20, 2007 2:19 PM Subject: [puntonet] HttpWebRequest Jaja Luis, no hay problema :) Gracias por las respuestas. Clarifico un poco la situacion: El codigo que mande no es el mio, es el que utiliza la entidad de Servicio de Pago para enviarme a mi, la informacion, es decir, yo de alguna forma tengo que recibir la informacion enviada y no tengo acceso al objeto HttpWebRequest (y por ende tampoco al HttpWebResponse) porque son dos paginas separadas.Segun he visto en varios foros, el objeto Request deberia tener en su InputStream, la informacion codificada que me envian, el problema en realidad es que mi pagina nunca ejecuta su Code-Behind por alguna razon. El Servicio de Pago, mediante su HttpWebRequest hace el POST, el IIS de mi servidor en su log registra el POST, pero mi pagina nunca recibe absolutamente nada. Puse un HttpHandler, que en su evento Application_EndRequest detecta el Request a mi pagina, pero la pagina no se "ejecuta", nada de su Code-Behind corre, ni siquiera la primera linea. Un problema casi igual aparecio en:http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1341362&SiteID=1 Matias From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: [puntonet] HttpWebRequestDate: Tue, 20 Mar 2007 13:51:15 -0300 No, no pregunten por qué puse Hugo, estoy teniendo serios problemas mentales, gracias. =P Perdón, Matías, ahora sí. From: Luis Farzati [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 20, 2007 13:49To: '[email protected]'Subject: RE: [puntonet] HttpWebRequest Hola Hugo, Una cosa que estoy notando, si querés enviar información raw (que por el ejemplo intuyo que sí), no tenés que especificar un ContentType de x-www-form-urlencoded. Hacé una cosa, probá comentando esa línea y fijate si te funciona. Por otro lado, a modo sugerencia, si la página a la que estás posteando está creada únicamente para eso, te convendría mejor que sea un HttpHandler que está pensado para eso. Además de por una cuestión formal y prolija, vas a tener mejor performance aunque esto sólo lo vas a notar en muy gran escala. Saludos! Luis From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Matias QSent: Tuesday, March 20, 2007 13:28To: [EMAIL PROTECTED]: [puntonet] HttpWebRequest Buen dia lista, Estamos implementando una interfaz con un servicio de pago para Bancos, Tarjetas de Credito, etc. Nuestro sistema es Web (.NET 2.0), redirige a una pagina del Servicio de Pago donde se valida la tarjeta/banco y luego ellos redirigen al cliente nuevamente a nuestro sistema, la pagina que luego recibe al cliente tiene un resumen de su pago (la informacion a esta pagina se recibe mediante un POST normal de un formulario, asi que utilizamos Request.Form para hacerlo). Al mismo tiempo, el Servicio de Pago, envia mediante un proceso interno mas informacion a traves de un HttpWebRequest a otra de nuestras paginas, no visible al cliente. El problema es que esta pagina que recibe el HttpWebRequest, no esta ejecutando ninguna linea de su Code-Behind, no ejecuta nada en absoluto. El Servicio de Pago lo envia de esta forma: HttpWebRequest request = (URL); request.ContentType = "application/x-www-form-urlencoded"; request.Method = "POST"; request.Accept = "text/*"; request.AllowAutoRedirect = false; UTF8Encoding Encoding = new UTF8Encoding(); byte[] postBytes = Encoding.GetBytes("informacion"); request.ContentLength = postBytes.Length; Stream requestStream = request.GetRequestStream(); requestStream.Write(postBytes, 0, postBytes.Length); requestStream.Close(); El HttpWebRequest tiene un encoding UTF8 y envia un string de datos, el POST llega a nuestro servidor y se registra en el IIS, pero la pagina no corre nada de su Code-Behind, ni una linea. El codigo de recepcion se esta ejecutando en el evento Page_Load, deberia ser en otro evento? Deberia tener algun tipo de header HTTP especial para recibir el HttpWebRequest? Tendra que ver con el Encoding? Si alguien puede iluminarme, lo agradeceria mucho. Matias Your friends are close to you. Keep them that way. i'm making a difference. Make every IM count for the cause of your choice. Join now! Your friends are close to you. Keep them that way. Your friends are close to you. Keep them that way. i'm making a difference. Make every IM count for the cause of your choice. Join now! Your friends are close to you. Keep them that way. _________________________________________________________________ i'm making a difference. Make every IM count for the cause of your choice. Join Now. http://clk.atdmt.com/MSN/go/msnnkwme0080000001msn/direct/01/?href=http://im.live.com/messenger/im/home/?source=wlmailtagline
