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: puntonet@mug.org.ar
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: puntonet@mug.org.ar
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: puntonet@mug.org.ar
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: 'puntonet@mug.org.ar'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: puntonet@mug.org.ar [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.
http://clk.atdmt.com/MSN/go/msnnkwme0080000001msn/direct/01/?href=http://im.live.com/messenger/im/home/?source=wlmailtagline
