shwango! blog

well, the prolific writer in me must have come to an end. just been busy – that’s the usual excuse for not posting, right? well, last week was busy, frustrating, but ultimately productive.

i solved the ms isa proxy issue with our application, thinkingfolders (tf). took a few days ’cause i’ve been focused on development over networking. i got a crash course in cisco switch configuration – we had a spare 2912 that i configured to mirror ethernet traffic from the internal nic of the isa box to a linux box running snort to log the http traffic being sent to/from our tf client applet. i also configured an external 2924 switch to mirror the external http traffic send to/from the isa box to moby (my laptop) running snort to capture those packets. (snort rocks – i’ll post more later)

the issue we had was that our applet, which makes soap requests to a servlet, would throw a internet file read error or something like that, after making the request – when ie was set to use the isa box for its proxy. this only happend when ie was set to use isa as a proxy, not with the firewall client installed, which worked perfectly.

last monday was when i actually setup my little test switched network. over that previous weekend i installed the squid proxy on my home adsl network firewall to see how well tf worked. things worked pretty well – no file read errors, at least. (i’ll have to revisit some caching issues later.)

one obstacle i overcame was that the ethernet adapter in moby’s docking station is only a 10 meg adapter which would not run in promiscuous mode – needed to capture packets not specifically destined for moby. using a usb 10/100 adapter i had lying around did the trick – linux detected the adapter as soon as i plugged it in!

i’m not an expert in tcp/ip so it took me a bit to figure out the snort output, but it wasn’t to tough since i’ve done some tcpdump stuff before. i did a capture using the proxy and one using the firewall client to get a “bad” dump and a “good” dump of the data.

after finding the packets that were been returned to the client, i noticed that after all the errors, one of the trailing packets contained the R flag. the R flag is to reset the connection. that was a big clue to the problem.

then I started to analize the http headers. i knew that the applet was having no problem loading static xml files. the problem arose when we issued a soap request that the request processor servlet would then send a dynamic response. so what did the headers show? well, the static files all had the standard fair that apache sends back, including “connection: keep-alive”. guess what the servlet’s http headers had, yup: “connection: close”.

this was telling the applet to close the connection. so what i’m assuming is that, since the request is actually being submitted by the proxy server, the request that gets back to the applet closes before the applet closes its input stream – even when it looks like the whole xml response is there.

so from there we tried coding the servlet to put the keep-alive headers in, but all we got back was a dual connection entry: “connection: keep-alive, close” which would close the connection still. so it was off to google to do some more searching.

since i knew what i was looking for, i found this cool article on keep-alives and java. what i did not know was that servlets put “connection: close” headers if the response is greater than 4k and you don’t send a content length header. once we knew that, we added one line of code to the servlet to send back the content length and, bam!, it worked! ahhh!

the boss bought us a 12 pack of beck’s!

one thing i still want to investigate is how proxies work at the tcp/ip level. isa seems to send http 1.0 headers (”via” header) instead of http 1.1 headers that ie sends, so i want to know what problems this will cause.