Forum Discussion

KellyS_50017's avatar
KellyS_50017
Icon for Nimbostratus rankNimbostratus
Apr 05, 2011

Postback download doesn't finish when running through the BigIP

We include a link to download a pdf of a client's rendered image and with how dodgey Adobe Reader's browser plugin has become over the last year, it is very hit or miss on a client's desktop.

 

So we rewrote our embedded link to do a sort of postback mime download from the server to your browser, so you are prompted to save the file rather than open it up in the Adobe Reader plugin installed in your browser.

 

 

 

So! Everything worked well enough we got to our first test environment utilizing F5's. You can start the download, but it never finishes. In Chrome, it stops around the 500k mark. In IE, it stops with a "Unable to download XXX from XXX.com. The connection with the server was reset".

 

 

 

If I hit the node ip directly, it works fine. If I hit it through the virtual server, it fails. So I don't mean to blame the F5, but it sure feels like the F5 is the issue.

 

 

 

We had some tweaked TCP & Http profiles, the first thing I did was set them back to the factory stock TCP & Http profiles, they made no difference.

 

 

 

Has anyone else see this? I've tried crawling the knowledge base but I am having a hard time finding the search terms that would fit. The closest knowledge base hits I can find are as if the F5 is sending TCP RST packets to a perceived DOS attack.

 

 

 

We're on 9.4.8 if that helps.

 

 

 

And, here's a link to an example. This is a non-prod server, these are just dummy awards with mocked up text. Click "View Award" for either of the two awards, then click "Download PDF" at the top of the page and you'll see what I mean.

 

https://pre.HallmarkBusiness.com/PO...PIN=1FEADE

 

 

config
design
  • KellyS_50017's avatar
    KellyS_50017
    Icon for Nimbostratus rankNimbostratus
    Apr 06, 2011
    Can you give me some examples on the information you are looking for?

     

     

    So far -

     

    We're running 9.4.8

     

    We're using the factory stock http & tcp profiles on the virtual server.

     

     

     

     

     

  • Joel_Moses's avatar
    Joel_Moses
    Icon for Nimbostratus rankNimbostratus
    Apr 06, 2011
    Can you try turning the selection on the HTTP profile for "Response Chunking" to "Rechunk"? If that has an impact, then we can probably zero in on this with an iRule by leaving it on the default of "Selective" and turning on rechunking just for the affected URIs.
  • KellyS_50017's avatar
    KellyS_50017
    Icon for Nimbostratus rankNimbostratus
    Apr 06, 2011
    SSL cert, I assume? Both. The clientssl profile has our VeriSign wildcard, the serverssl profile has an internally created wildcard that is also on the web tier.

     

     

    -Kelly

     

  • KellyS_50017's avatar
    KellyS_50017
    Icon for Nimbostratus rankNimbostratus
    Apr 06, 2011
    I made an http_Rechunk profile with it turned to Rechunk, set it to use it, and the only difference is now the browser doesn't see the full file size before the download starts. It still dies 500k-600k into the download.
  • Jonathan_Scholi's avatar
    Jonathan_Scholi
    Icon for Cirrostratus rankCirrostratus
    Apr 06, 2011
    Is there any chance of putting the VeriSign wildcard on your internal server? This would allow you to switch the virtual server type from "Standard" to "Performance (Layer 4)".
  • KellyS_50017's avatar
    KellyS_50017
    Icon for Nimbostratus rankNimbostratus
    Apr 08, 2011
    We're ruminating on the ssl cert thing; it would a certain amount of work and we'd be breaking some security rules to do it.

     

     

    We're working with Fishnet Security at the same time on this. We've taken tcpdumps and ssldumps on both nics (leading external and leading to the node vlan), and depending on how you read the results, it does appear the resets are originating from the BigIP LTM and being sent to the client. The web server never sees any of this. There's a question whether or not the resets could be coming from the Nokia/Checkpoint device that sits between the LTM and the Interwebs, but the general consensus is it's coming from the LTM.

     

     

     

    We've turned off oneconnect transformations, pipelining and all compression, it's made no difference.

     

     

     

    We have to launch this major release tonight, so we had development roll the code back in our non-prod environments. They preserved an example of the problem in our eyechart page. Go here:

     

    https://pre.hallmarkbusiness.com/eyechart.aspx

     

     

     

    and click on the second "download printable award" link. Then try opening the pdf you just downloaded - Acrobat Reader will say it's corrupt. The first ~500k isn't corrupt, it's just missing the rest.