« Previous Next »

• 04-03-2009, 1:14 AM

  azzteroid Joined on 04-03-2009, 3:38 AM Australia Posts 5

  Blank Post from ie7 Reply Contact Hi we are currently experiencing issues with ie7 posting not form data to our server. With .net trace turned on we have captured one of these error posts and can see that the HTTP_CONTENT_LENGTH is 0. We are running IIS 6 and have a mixture of classic asp and asp.net applications. We have been unable to replicate this error on any of the test machines we have tried so far. This error only seems to be experienced by particular clients. The number of people experiencing this issue is increasing as more of our clients migrate to vista. The main customer experiencing the issue runs ISA 2004 as their proxy server. The error also presents itself inconsistently within affected organisations with some users experiencing the errors and other not. With those experiencing the error not even experiencing it every time. Thanks in Advance

  Tags: IE7ASP.NETIIS6

• 04-04-2009, 5:40 AM

  In reply to

  lextm Joined on 10-22-2008, 4:18 AM Shanghai, PRC Posts 1,430

  Re: Blank Post from ie7 Reply Contact If this site is not SSL protected, you can set up Microsoft Network Monitor on both a problematic client and the server. Then you can reproduce this problem with traffic captured on both side. First, we need to determine when does the POST data disappear. If we are sure that when the packet leaves the client it is already empty then we can focus on IE. Otherwise, this data is lost in between. Lex Li Support Engineer at Microsoft --------------------------- This posting is provided "AS IS" with no warranties, and confers no rights.

• 04-05-2009, 8:36 PM

  In reply to

  azzteroid Joined on 04-03-2009, 3:38 AM Australia Posts 5

  Re: Blank Post from ie7 Reply Contact Thanks for your reply. Unfortunatly our clients are indirect clients and so installing network monitoring software on their machines is not really an option. Whilst we could run the monitor on our server with the lack of prior knowledge of when we will experience the error I am worried about the performance implications of running network monitoring software over an extended period of time on our busy production server. I guess this leaves me trying to find a reproducable case so I can monitor in a more controlled manor. Without the network monitoring information are you aware of any common circumstances that could cause such an error so that I am able to rule these out while trying to move towards a more testable situation.

• 04-05-2009, 9:12 PM

  In reply to

  lextm Joined on 10-22-2008, 4:18 AM Shanghai, PRC Posts 1,430

  Re: Blank Post from ie7 Reply Contact I can see it is hard to troubleshoot the problem on a production server. But using Network Monitor is a necessary step to narrow down the problem. We must first identify if this problem is caused by the client, the network in between, or the server and then we can try to find a solution. Can you try to capture traffic in non-business hours? That may minimize the impact. Lex Li Support Engineer at Microsoft --------------------------- This posting is provided "AS IS" with no warranties, and confers no rights.

• 04-05-2009, 9:39 PM

  In reply to

  azzteroid Joined on 04-03-2009, 3:38 AM Australia Posts 5

  Re: Blank Post from ie7 Reply Contact Thanks again for your reply. Unfortunately our business hours are 24 hours a day and as we will need to capture real users experiencing the error due to our inability to replicate the error ourselves we will need to capture while server is under normal load. Looks like we'll need to do some testing of the impact of capturing traffic on our development server and work out a plan for doing so on production. We will post more information when we have it available.

• 04-16-2009, 12:13 AM

  In reply to

  azzteroid Joined on 04-03-2009, 3:38 AM Australia Posts 5

  Re: Blank Post from ie7 Reply Contact We have managed to capture an incoming post from the client which causes the error. We still haven't got a client side capture due to the difficulty of establishing a direct line with a client who can reproduce the error who has relevant permission / ability to perform network monitoring.      Frame: Number = 9853, Captured Frame Length = 1077, MediaType = ETHERNET - Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[###########],SourceAddress:[##########]   - DestinationAddress: VMWare, Inc. 8D6B2A [###############]      IG:  (0.......) Individual address      UL:  (.0......) Universally Administered Address      Rsv: (..000000)   - SourceAddress: Fortinet Inc. 090000 [###############]      UL: .0...... Universally Administered Address     EthernetType: Internet IP (IPv4), 2048(0x800) - Ipv4: Src = ############, Dest = #########, Next Protocol = TCP, Packet ID = 51719, Total IP Length = 1063   - Versions: IPv4, Internet Protocol; Header Length = 20      Version:      (0100....) IPv4, Internet Protocol      HeaderLength: (....0101) 20 bytes (0x5)   - DifferentiatedServicesField: DSCP: 0, ECN: 0      DSCP: (000000..) Differentiated services codepoint 0      ECT:  (......0.) ECN-Capable Transport not set      CE:   (.......0) ECN-CE not set     TotalLength: 1063 (0x427)     Identification: 51719 (0xCA07)   - FragmentFlags: 16384 (0x4000)      Reserved: (0...............)      DF:       (.1..............) Do not fragment      MF:       (..0.............) This is the last fragment      Offset:   (...0000000000000) 0     TimeToLive: 48 (0x30)     NextProtocol: TCP, 6(0x6)     Checksum: 58238 (0xE37E)     SourceAddress: ###########     DestinationAddress: ######### - Tcp: Flags=...AP..., SrcPort=53991, DstPort=HTTP(80), PayloadLen=1011, Seq=4164216244 - 4164217255, Ack=2415043762, Win=5840 (scale factor 0x0) = 5840     SrcPort: 53991     DstPort: HTTP(80)     SequenceNumber: 4164216244 (0xF834E5B4)     AcknowledgementNumber: 2415043762 (0x8FF2A4B2)   - DataOffset: 128 (0x80)      DataOffset: (1000....) 32 bytes      Reserved:   (....000.)      NS:         (.......0) Nonce Sum not significant   - Flags: ...AP...      CWR:    (0.......) CWR not significant      ECE:    (.0......) ECN-Echo not significant      Urgent: (..0.....) Not Urgent Data      Ack:    (...1....) Acknowledgement field significant      Push:   (....1...) Push Function      Reset:  (.....0..) No Reset      Syn:    (......0.) Not Synchronize sequence numbers      Fin:    (.......0) Not End of data     Window: 5840 (scale factor 0x0) = 5840     Checksum: 0x9D2E, Good     UrgentPointer: 0 (0x0)   - TCPOptions:    - NoOption:       type: No operation. 1(0x1)    - NoOption:       type: No operation. 1(0x1)    - TimeStamp:       type: Timestamp. 8(0x8)       Length: 10 (0xA)       TimestampValue: 1427302923 (0x5512EA0B)       TimestampEchoReply: 0 (0x0) - Http: Request, POST /qol6.0/de/SpecOrder.aspx     Command: POST   - URI: /qol6.0/de/SpecOrder.aspx      Location: /qol6.0/de/SpecOrder.aspx     ProtocolVersion: HTTP/1.0     Cookie:  SessionID=##################; ASPSESSIONIDSSQSQSDC=JPAKJACDCFBLBECBGEPCBNBB; SessionID=########     ContentType:  application/x-www-form-urlencoded     UserAgent:  Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)     Host:  ##############     Accept:  image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*     Referer:  ###########/qol6.0/qmgtrmq.asp?ThisPage=qmgtrm01&Option=#######     Accept-Language:  en-nz     UA-CPU:  x86     Pragma:  no-cache     ContentLength:  0     Via:  1.1 FFX400, 1.1 proxy1.#####.net:80 (squid/2.5.STABLE3), 1.0 proxy1.#####.net:8082 (squid/2.5.STABLE3)     X-Forwarded-For:  ######, #####     Cache-Control:  max-age=259200     Connection:  keep-alive     HeaderEnd: CRLF

• 04-16-2009, 1:31 AM

  In reply to

  lextm Joined on 10-22-2008, 4:18 AM Shanghai, PRC Posts 1,430

  Re: Blank Post from ie7 Reply Contact Let's wait till we can capture the packets from client side. Note that "ContentLength:  0" from the packet you captured on server side reveals that actually IIS was receiving empty POST packets from its NIC, and this problem was not caused by IIS. Lex Li Support Engineer at Microsoft --------------------------- This posting is provided "AS IS" with no warranties, and confers no rights.

• 10-14-2009, 12:25 PM

  In reply to

  fernando.olivo Joined on 10-14-2009, 4:21 PM Posts 1	Re: Blank Post from ie7 Reply Contact Hi, Seems like I have the same situation as you have experienced. Did you sort this out ? I mean, Is this history has a happy end ? if yes, what actions did you make ? Thanks in Advance Fernando

• 10-14-2009, 6:19 PM

  In reply to

  azzteroid Joined on 04-03-2009, 3:38 AM Australia Posts 5	Re: Blank Post from ie7 Reply Contact  Hi, unfortunately we have not sorted out this issue yet. We have still been unable to either replicate or find a suitable client who is able to do client side packet capturing for us. I will let you know if we do end up sorting it out. Please let me know if you have any success. Thanks

• 10-26-2009, 6:29 AM

  In reply to

  GRIFFMG Joined on 10-26-2009, 10:27 AM Posts 1	Re: Blank Post from ie7 Reply Contact I'm getting the exact same problem - I've tried all the things I can think of and today I have the user about to install FireFox and try that instead of IE. They are a very large company, and it's not easy to get things done on end-users PCs... If anyone comes across a solution I would be very grateful