locked
IE8 request header error on HTTPS RRS feed

  • Question

  • While trying to access Secure page (HTTPS) on a server, the GET request header is not sent properly. The header is split into two different messages. Only the first byte "G" is received by the server as one complete message and then the rest of the bytes are received "ET....." . This is happening only on IE8(8.0.7601.17514CO). But it works fine on IE7(7.0.5730.13), IE8(8.0.6001.18702CO) and IE9(9.0.8112.16421CO) for the same secure page. Can anyone guide on the same?
    Thursday, April 11, 2013 5:26 AM

Answers

  • I searched for, but couldn't find such issues reported for the particular IE8 version i.e., 8.0.7601.17514CO

    Do you have any hotfixes applied to that OS?  Sounds like a bad patch and I would still suspect the OS before IE, e.g. something wasn't broken (which IE7 was using), was fixed improperly and then used by IE8 and then finally was fixed properly (for IE9).  IEDiagCmd.exe  might provide some clues along those lines.  However, I'm not sure when it was first made available, e.g. whether there was one for IE7.   In fact, I doubt that it will really be that helpful because what we really would want is a breakout of patches in terms of SUPs and COREQs and I have never seen Microsoft provide anything like that (in contrast to IBM for example.)

    Otherwise, assuming you are only on the GDR track an alternative tack would be to get completely on the LDR track and see if your symptom changes.   I once used a modification of the method described by Pronichkin to do that.

    http://social.technet.microsoft.com/wiki/contents/articles/3323.how-to-forcibly-install-the-ldr-branch-from-a-particular-hotfix-package.aspx

     
    Good luck

     
    Robert
    ---

    • Marked as answer by tracycai Thursday, April 25, 2013 8:08 AM
    Monday, April 22, 2013 4:06 PM
    Answerer

All replies

  • Hi,

    Please refer to the reply by Karen and see if it resolve your issue.

    http://social.technet.microsoft.com/Forums/en-US/w7itpronetworking/thread/9a0c9dfa-6d04-48e9-8620-10578386203a

    Thanks.


    Tracy Cai
    TechNet Community Support

    Friday, April 12, 2013 7:36 AM
  • I had posted that question. Tried the solution provided, but it didn't work out.
    • Edited by SupriyaRoy Friday, April 12, 2013 8:40 AM
    Friday, April 12, 2013 8:40 AM
  • I had posted that question.

    I think you were in the right forum in the first place.   I have never seen an HTTP request header transmitted and received as separate characters.   That sounds like a Networking problem to me, which is where you had posted.  So, what does this look like using NetMon (or WireShark) e.g. at the TCP level?

    However, your example shows something that I have often wondered about using telnet 80 as a simulation tool.  E.g. what happens to each character we type initially when the screen clears?  G E T   /   

    FWIW I can't really recall ever getting a 501 by being slow doing that.   I just tried it with www.microsoft.com and just got closed with no response at all.  

    You might get more insight on your particular symptom by running Fiddler2 for its Request Builder tool.   In fact, since Fiddler is a proxy you might even find that you could use it as a workaround, though because your scenario involves a secure connection you would be subject to the symptom of a perceived problem with certificates due to Fiddler's "man-in-the-middle" status.

    FYI

     
    Robert Aldwinckle
    ---

    Friday, April 12, 2013 3:12 PM
    Answerer
  • Hi Robert,

    I was using WireShark to see the packets at the TCP level. It shows two encrypted Application data in SSL in the same packet for the request header. However, I was unable to decrypt the packets due to certificate issues, so I'm not sure what it really sent. But, for the same secure page it was showing only one Application data in the SSL of the packet for the other versions wherein it was displaying the page correctly.

    The interesting thing to note is, the breaking of the request header into different packets is obviously possible, but breaking just after the very first byte seems a bit odd. We can anyway handle it at the receiving end by waiting for the entire packet before processing the request method type, but this behavior of send buffer implementation is erroneous on part of IE8 ( 8.0.7601.17514CO ) which other versions don't seem to have.

    I searched for, but couldn't find such issues reported for the particular IE8 version i.e., 8.0.7601.17514CO  . Also, nothing has been mentioned on MS support/documentation regarding the same. 

    Please help ensuring the same.

    Regards,
    SupriyaRoy

    Monday, April 22, 2013 6:14 AM
  • I searched for, but couldn't find such issues reported for the particular IE8 version i.e., 8.0.7601.17514CO

    Do you have any hotfixes applied to that OS?  Sounds like a bad patch and I would still suspect the OS before IE, e.g. something wasn't broken (which IE7 was using), was fixed improperly and then used by IE8 and then finally was fixed properly (for IE9).  IEDiagCmd.exe  might provide some clues along those lines.  However, I'm not sure when it was first made available, e.g. whether there was one for IE7.   In fact, I doubt that it will really be that helpful because what we really would want is a breakout of patches in terms of SUPs and COREQs and I have never seen Microsoft provide anything like that (in contrast to IBM for example.)

    Otherwise, assuming you are only on the GDR track an alternative tack would be to get completely on the LDR track and see if your symptom changes.   I once used a modification of the method described by Pronichkin to do that.

    http://social.technet.microsoft.com/wiki/contents/articles/3323.how-to-forcibly-install-the-ldr-branch-from-a-particular-hotfix-package.aspx

     
    Good luck

     
    Robert
    ---

    • Marked as answer by tracycai Thursday, April 25, 2013 8:08 AM
    Monday, April 22, 2013 4:06 PM
    Answerer