There should be one or more devices inserted in (a) > client browser (port 2345) --(a)--> (port 80) apache ---(b)---> mod_jk (port > 1234) ---(c)---> (port 8109) tomcat --> DB
There should be a firewall, or who knows what a hacker may have inserted. There might be a load balancer. If either of these is misconfigured then who knows. The technique that everyone is suggesting is a form of "Divide and Conquer" - and is something that every programmer must learn to employ. Refusal is a waste of everyone's time including the OP. http://en.wikipedia.org/wiki/Divide_and_conquer_algorithm Regards, Dave On Aug 11, 2010, at 9:04 AM, André Warnier wrote: > Karthik, > > let me try again : > > Karthik Nanjangude wrote: >> Hi >>>> Maybe you could try a capture from the client system (the one >> w/ a browser open). >> As I have already posted the form [ please check last few mails exchanged ] >> If the Sample test on the web application is performed from Outer side world >> [http://www.xyx.com/abcd ] >> Tcp dump captured on Apache Http Server, 2 Post request are clearly visible >> with 12 sec apart. > > If the Sample test on the same hosted web application performed from within > > the internally IP/Port hosted [ http://xyx/abcd ] > > > > Tcp dump captured on JBoss [Tomcat Built in ] 1 Post request is visible > > > > Let me use my graphic artwork again : > > case a) > > client browser (port 2345) --(a)--> (port 80) apache ---(b)---> mod_jk (port > 1234) ---(c)---> (port 8109) tomcat --> DB > > result (per trace on (c)): 2 POSTs (and 2 rows in database DB) > > case b) > > client browser (port 2345) ----(d)---> (port 8080 or 8180..) tomcat --> DB > > result (per trace on (d) ?): 1 POST (in database DB) > > > What you have told us so far, is that when you watch the TCP traffic in (c) > above, you see 2 POST requests, from port 1234 (mod_jk) to port 8109 (tomcat > AJP connector). > > But because these are on the internal link between Apache and Tomcat, it is > difficult for us to see if these are really the /same/ request, duplicated by > Apache/mod_jk, or just two totally unrelated POST requests from different > clients. > That is because, at the level of (c), ALL requests will look like they come > from port 1234 (mod_jk) to port 8109 (tomcat). > > > What you have NOT proven to us so far, is that those 2 POST requests are NOT > also in (a). > THAT is what we want to know, at 100%. > > We want to know this, because we believe that Apache or mod_jk do not just > duplicate POST requests. We do not believe that they do that, because if > they did that, then you would not be the only person to mention this problemm > and there would be LOTS of peoplehaving problems with their bank accounts. > > Currently, we believe that it is about 10,000 times more probable, that the 2 > POST requests are generated by something not working as you expect, but /on > the browser side/. > > Maybe we are wrong. > But to change our belief, you will have to bring real proof. > You are going to have to show us a trace done at the level (a), showing 1 > single POST request, and a trace done at the same time at the level (c), > showing 2 POST requests. > > > >> If the Sample test on the same hosted web application performed from within >> the internally IP/Port hosted [ http://xyx/abcd ] >> Tcp dump captured on JBoss [Tomcat Built in ] 1 Post request is visible >> Both of the samples were verified in 2 Browsers [IE 7+ / FF3 +] more then 6 >> times and the info is captured via tcp Dump. >>>> request with wget rather than browsers >> Since the Application is in Production and need some Window Time for taking >> samples. >> I would definitely get back with the results by EOD 2 morrow >> With regards >> Karthik >> -----Original Message----- >> From: David Smith [mailto:d...@cornell.edu] >> Sent: Wednesday, August 11, 2010 7:23 PM >> To: Tomcat Users List >> Subject: Re: 2 POST requests to underlying Server >> Any chance we could see a snippet of access log showing the two >> requests? All I really see here is two packet captures that *look* like >> they are from in between tomcat and iis (or whatever you are running as >> a front-end web server). Since 10 addresses are not routeable this >> looks like all internal traffic. Any chance you could verify this is >> happening (or not) between the client browser and your front-end web >> server? Maybe you could try a capture from the client system (the one >> w/ a browser open). >> --David >> On 8/11/10 2:08 AM, Karthik Nanjangude wrote: >>> Hi >>> >>> Ok I have copied the wire shark test samples for the 2 Post Requests [ >>> Apache to JBOSS (Tomcat Internal )..This was taken Aug 9, 2010 >>> >>> >>> >>> >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> 1nd Post Request >>> >>> No. Time Source Destination Protocol >>> Info >>> 10022 30.516874 10.151.41.160 10.151.41.163 TCP >>> 33403 > 8109 [PSH, ACK] Seq=2079 Ack=4544 Win=15600 Len=65 TSV=2265749122 >>> TSER=2977204079 >>> >>> Frame 10022 (131 bytes on wire, 131 bytes captured) >>> Arrival Time: Aug 9, 2010 15:30:35.485640000 >>> [Time delta from previous captured frame: 0.000024000 seconds] >>> [Time delta from previous displayed frame: 30.516874000 seconds] >>> [Time since reference or first frame: 30.516874000 seconds] >>> Frame Number: 10022 >>> Frame Length: 131 bytes >>> Capture Length: 131 bytes >>> [Frame is marked: True] >>> [Protocols in frame: eth:ip:tcp:data] >>> [Coloring Rule Name: TCP] >>> [Coloring Rule String: tcp] >>> Ethernet II, Src: HewlettP_f8:fc:ea (00:24:81:f8:fc:ea), Dst: >>> HewlettP_f8:7d:9c (00:24:81:f8:7d:9c) >>> Destination: HewlettP_f8:7d:9c (00:24:81:f8:7d:9c) >>> Address: HewlettP_f8:7d:9c (00:24:81:f8:7d:9c) >>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast) >>> .... ..0. .... .... .... .... = LG bit: Globally unique address >>> (factory default) >>> Source: HewlettP_f8:fc:ea (00:24:81:f8:fc:ea) >>> Address: HewlettP_f8:fc:ea (00:24:81:f8:fc:ea) >>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast) >>> .... ..0. .... .... .... .... = LG bit: Globally unique address >>> (factory default) >>> Type: IP (0x0800) >>> Internet Protocol, Src: 10.151.41.160 (10.151.41.160), Dst: 10.151.41.163 >>> (10.151.41.163) >>> Version: 4 >>> Header length: 20 bytes >>> Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) >>> 0000 00.. = Differentiated Services Codepoint: Default (0x00) >>> .... ..0. = ECN-Capable Transport (ECT): 0 >>> .... ...0 = ECN-CE: 0 >>> Total Length: 117 >>> Identification: 0x0d18 (3352) >>> Flags: 0x02 (Don't Fragment) >>> 0.. = Reserved bit: Not Set >>> .1. = Don't fragment: Set >>> ..0 = More fragments: Not Set >>> Fragment offset: 0 >>> Time to live: 64 >>> Protocol: TCP (0x06) >>> Header checksum: 0xc4fa [correct] >>> [Good: True] >>> [Bad : False] >>> Source: 10.151.41.160 (10.151.41.160) >>> Destination: 10.151.41.163 (10.151.41.163) >>> Transmission Control Protocol, Src Port: 33403 (33403), Dst Port: 8109 >>> (8109), Seq: 2079, Ack: 4544, Len: 65 >>> Source port: 33403 (33403) >>> Destination port: 8109 (8109) >>> [Stream index: 64] >>> Sequence number: 2079 (relative sequence number) >>> [Next sequence number: 2144 (relative sequence number)] >>> Acknowledgement number: 4544 (relative ack number) >>> Header length: 32 bytes >>> Flags: 0x18 (PSH, ACK) >>> 0... .... = Congestion Window Reduced (CWR): Not set >>> .0.. .... = ECN-Echo: Not set >>> ..0. .... = Urgent: Not set >>> ...1 .... = Acknowledgement: Set >>> .... 1... = Push: Set >>> .... .0.. = Reset: Not set >>> .... ..0. = Syn: Not set >>> .... ...0 = Fin: Not set >>> Window size: 15600 (scaled) >>> Checksum: 0x2b50 [validation disabled] >>> [Good Checksum: False] >>> [Bad Checksum: False] >>> Options: (12 bytes) >>> NOP >>> NOP >>> Timestamps: TSval 2265749122, TSecr 2977204079 >>> [SEQ/ACK analysis] >>> [Number of bytes in flight: 1134] >>> Data (65 bytes) >>> >>> 0000 12 34 00 3d 00 3b 73 69 6d 3d 38 39 36 30 31 39 .4.=.;sim=896019 >>> 0010 39 39 30 30 32 30 34 32 36 33 37 35 26 63 61 6e 990020426375&can >>> 0020 6d 73 69 73 64 6e 3d 31 30 35 32 37 37 37 37 37 msisdn=105277777 >>> 0030 26 61 63 63 6f 75 6e 74 69 64 3d 36 37 39 37 35 &accountid=67975 >>> 0040 31 1 >>> Data: 1234003D003B73696D3D3839363031393939303032303432... >>> [Length: 65] >>> >>> >>> >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> 2nd Post Request >>> >>> No. Time Source Destination Protocol >>> Info >>> 15548 42.619208 10.151.41.160 10.151.41.163 TCP >>> 33418 > 8109 [PSH, ACK] Seq=1075 Ack=6 Win=5840 Len=65 TSV=2265761224 >>> TSER=2977216182 >>> >>> Frame 15548 (131 bytes on wire, 131 bytes captured) >>> Arrival Time: Aug 9, 2010 15:30:47.587974000 >>> [Time delta from previous captured frame: 0.000009000 seconds] >>> [Time delta from previous displayed frame: 12.102334000 seconds] >>> [Time since reference or first frame: 42.619208000 seconds] >>> Frame Number: 15548 >>> Frame Length: 131 bytes >>> Capture Length: 131 bytes >>> [Frame is marked: True] >>> [Protocols in frame: eth:ip:tcp:data] >>> [Coloring Rule Name: TCP] >>> [Coloring Rule String: tcp] >>> Ethernet II, Src: HewlettP_f8:fc:ea (00:24:81:f8:fc:ea), Dst: >>> HewlettP_f8:7d:9c (00:24:81:f8:7d:9c) >>> Destination: HewlettP_f8:7d:9c (00:24:81:f8:7d:9c) >>> Address: HewlettP_f8:7d:9c (00:24:81:f8:7d:9c) >>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast) >>> .... ..0. .... .... .... .... = LG bit: Globally unique address >>> (factory default) >>> Source: HewlettP_f8:fc:ea (00:24:81:f8:fc:ea) >>> Address: HewlettP_f8:fc:ea (00:24:81:f8:fc:ea) >>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast) >>> .... ..0. .... .... .... .... = LG bit: Globally unique address >>> (factory default) >>> Type: IP (0x0800) >>> Internet Protocol, Src: 10.151.41.160 (10.151.41.160), Dst: 10.151.41.163 >>> (10.151.41.163) >>> Version: 4 >>> Header length: 20 bytes >>> Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) >>> 0000 00.. = Differentiated Services Codepoint: Default (0x00) >>> .... ..0. = ECN-Capable Transport (ECT): 0 >>> .... ...0 = ECN-CE: 0 >>> Total Length: 117 >>> Identification: 0x2ad0 (10960) >>> Flags: 0x02 (Don't Fragment) >>> 0.. = Reserved bit: Not Set >>> .1. = Don't fragment: Set >>> ..0 = More fragments: Not Set >>> Fragment offset: 0 >>> Time to live: 64 >>> Protocol: TCP (0x06) >>> Header checksum: 0xa742 [correct] >>> [Good: True] >>> [Bad : False] >>> Source: 10.151.41.160 (10.151.41.160) >>> Destination: 10.151.41.163 (10.151.41.163) >>> Transmission Control Protocol, Src Port: 33418 (33418), Dst Port: 8109 >>> (8109), Seq: 1075, Ack: 6, Len: 65 >>> Source port: 33418 (33418) >>> Destination port: 8109 (8109) >>> [Stream index: 257] >>> Sequence number: 1075 (relative sequence number) >>> [Next sequence number: 1140 (relative sequence number)] >>> Acknowledgement number: 6 (relative ack number) >>> Header length: 32 bytes >>> Flags: 0x18 (PSH, ACK) >>> 0... .... = Congestion Window Reduced (CWR): Not set >>> .0.. .... = ECN-Echo: Not set >>> ..0. .... = Urgent: Not set >>> ...1 .... = Acknowledgement: Set >>> .... 1... = Push: Set >>> .... .0.. = Reset: Not set >>> .... ..0. = Syn: Not set >>> .... ...0 = Fin: Not set >>> Window size: 5840 (scaled) >>> Checksum: 0xbd20 [validation disabled] >>> [Good Checksum: False] >>> [Bad Checksum: False] >>> Options: (12 bytes) >>> NOP >>> NOP >>> Timestamps: TSval 2265761224, TSecr 2977216182 >>> [SEQ/ACK analysis] >>> [Number of bytes in flight: 1134] >>> Data (65 bytes) >>> >>> 0000 12 34 00 3d 00 3b 73 69 6d 3d 38 39 36 30 31 39 .4.=.;sim=896019 >>> 0010 39 39 30 30 32 30 34 32 36 33 37 35 26 63 61 6e 990020426375&can >>> 0020 6d 73 69 73 64 6e 3d 31 30 35 32 37 37 37 37 37 msisdn=105277777 >>> 0030 26 61 63 63 6f 75 6e 74 69 64 3d 36 37 39 37 35 &accountid=67975 >>> 0040 31 1 >>> Data: 1234003D003B73696D3D3839363031393939303032303432... >>> [Length: 65] >>> >>> >>> >>> With regards >>> Karthik >>> >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Karthik Nanjangude [mailto:karthik.nanjang...@xius-bcgi.com] >>> Sent: Wednesday, August 11, 2010 11:03 AM >>> To: Tomcat Users List >>> Subject: RE: 2 POST requests to underlying Server >>> >>> Hi >>> >>> >>>>> wireshark or tcpdump running on the external + internal segments >>>>> simultaneously. >>>>> >>> I can provide u the tcp dump samples which we used to validate using White >>> shark. >>> >>> >>> Of course I need some time (probably by EOD ) to get permission from my >>> authorities for the same. >>> >>> Is this ok with u >>> >>> >>> With regards >>> KArthik >>> >>> -----Original Message----- >>> From: Hassan Schroeder [mailto:hassan.schroe...@gmail.com] >>> Sent: Wednesday, August 11, 2010 10:49 AM >>> To: Tomcat Users List >>> Subject: Re: 2 POST requests to underlying Server >>> >>> On Tue, Aug 10, 2010 at 10:07 PM, Karthik Nanjangude >>> <karthik.nanjang...@xius-bcgi.com> wrote: >>> >>> >>>> The same test performed on the Internal IP (http://<ip:port>/ABCD), and >>>> was observed that the single Post request was observed with single >>>> Insertion to DB ... compared to 2 POST request via External IO ( >>>> http://ABCD.com ) >>>> >>>> So how does this prove that the JavaScript as stated below is not working >>>> .... :( >>>> >>> Forget the browser and the JavaScript -- reproduce the problem using >>> wget or curl or something basic to initiate your request, with wireshark >>> or tcpdump running on the external + internal segments simultaneously. >>> >>> Then you'll have some interesting data :-) >>> >>> -- >>> Hassan Schroeder ------------------------ hassan.schroe...@gmail.com >>> twitter: @hassan >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
