Forum Discussion

WL_109786's avatar
WL_109786
Icon for Nimbostratus rankNimbostratus
Dec 31, 2009

F5 and Websphere - 404 page error

I apologized if I post in a wrong section.

 

 

Issue:

 

When we hit the site with http, it should redirect us to https instead we will get 404 error. When this happened, we have to failover to the standby F5 and everything will be fine again. We used to have this problem occurred every couple of days but after we made a few changes to the http rule everything seems to be a little more stable and this only occurred one after couple weeks (basically we just made it simple and use mostly default settings since it will be redirected to https). We took some TCPDump, and it seems to be when the problem occurred, it keep redirecting us to the following. Beside, when we hit the websevrer directly (bypassing F5), we will not see this problem.

 

 

F5 LTM (active/standby) --> 2 Web servers (IIS 6 proxy plugins) --> WAS (v7.0.0.5) + WP (v6.1.2)

 

Version BIG-IP 9.4.7 Build 326.1 Hotfix HF1

 

 

Rules on F5 for this site:

 

 

* We set this up using this guide - http://www.f5.com/pdf/deployment-guides/websphere-bigip9-dg.pdf

 

 

* fallback persistence profile we set to “none”

 

 

1) http virtual server (simple irule redirect all traffics to https)

 

 

2) https virtual server

 

 

 

HTTP/1.1 301 Moved Permanently

 

 

Server: Microsoft-IIS/6.0

 

 

Location: /wps/contenthandler/mm/!ut/p/spa//6_1LFQFV3300O800IOVSB89B2085/h

 

 

tml/mmsi?digest=N_5daMHgbyRiOPvt7gua6g!!

 

 

Content-Language: en-US

 

 

Server: WebSphere Application Server/7.0

 

 

Accept-Ranges: bytes

 

 

Connection: Keep-Alive

 

 

Date: Mon, 28 Dec 2009 16:29:53 GMT

 

 

Content-Length: 0

 

 

 

 

 

 

---------------------------------------------------------------

 

 

3 12 0.5107 (0.0849) C>S application_data

 

 

---------------------------------------------------------------

 

 

GET /wps/contenthandler/mmsi/!ut/p/spa//6_1LFQFV3300O800IOVSB89B2085/html/mm

 

 

si?digest=N_5daMHgbyRiOPvt7gua6g!! HTTP/1.1

 

 

Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/vnd.ms-

 

 

excel, application/vnd.ms-powerpoint, application/msword, application/x-silverli

 

 

ght, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xps

 

 

document, application/xaml+xml, application/x-silverlight-2-b2, application/x-sh

 

 

ockwave-flash, */*

 

 

Accept-Language: en-us

 

 

User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0;

 

 

InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET

 

 

CLR 3.0.4506.2152; .NET CLR 3.5.30729; MS-RTC LM 8)

 

 

Accept-Encoding: gzip, deflate

 

 

Host: www.mmsiservices.com

 

 

Connection: Keep-Alive

 

 

 

 

---------------------------------------------------------------

 

 

3 13 0.5368 (0.0261) S>C application_data

 

 

---------------------------------------------------------------

 

 

48 54 54 50 2f 31 2e 31 20 34 30 34 20 4e 6f 74 HTTP/1.1 404 Not

 

 

20 46 6f 75 6e 64 0d 0a 43 6f 6e 6e 65 63 74 69 Found..Connecti

 

 

6f 6e 3a 20 4b 65 65 70 2d 41 6c 69 76 65 0d 0a on: Keep-Alive..

 

 

44 61 74 65 3a 20 4d 6f 6e 2c 20 32 38 20 44 65 Date: Mon, 28 De

 

 

63 20 32 30 30 39 20 31 36 3a 32 39 3a 33 34 20 c 2009 16:29:34

 

 

47 4d 54 0d 0a 53 65 72 76 65 72 3a 20 4d 69 63 GMT..Server: Mic

 

 

72 6f 73 6f 66 74 2d 49 49 53 2f 36 2e 30 0d 0a rosoft-IIS/6.0..

 

 

41 63 63 65 70 74 2d 52 61 6e 67 65 73 3a 20 62 Accept-Ranges: b

 

 

79 74 65 73 0d 0a 58 2d 52 65 71 75 65 73 74 2d ytes..X-Request-

 

 

44 69 67 65 73 74 3a 20 4e 5f 35 64 61 4d 48 67 Digest: N_5daMHg

 

 

62 79 52 69 4f 50 76 74 37 67 75 61 36 67 21 21 byRiOPvt7gua6g!!

 

 

0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 ..Content-Type:

 

 

74 65 78 74 2f 68 74 6d 6c 3b 63 68 61 72 73 65 text/html;charse

 

 

74 3d 55 54 46 2d 38 0d 0a 24 57 53 45 50 3a 20 t=UTF-8..$WSEP:

 

 

0d 0a 43 6f 6e 74 65 6e 74 2d 4c 61 6e 67 75 61 ..Content-Langua

 

 

67 65 3a 20 65 6e 2d 55 53 0d 0a 53 65 72 76 65 ge: en-US..Serve

 

 

72 3a 20 57 65 62 53 70 68 65 72 65 20 41 70 70 r: WebSphere App

 

 

6c 69 63 61 74 69 6f 6e 20 53 65 72 76 65 72 2f lication Server/

 

 

37 2e 30 0d 0a 56 61 72 79 3a 20 41 63 63 65 70 7.0..Vary: Accep

 

 

74 2d 45 6e 63 6f 64 69 6e 67 0d 0a 43 6f 6e 74 t-Encoding..Cont

 

 

65 6e 74 2d 45 6e 63 6f 64 69 6e 67 3a 20 67 7a ent-Encoding: gz

 

 

69 70 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 ip..Content-Leng

 

 

74 68 3a 20 38 32 0d 0a 0d 0a 1f 8b 08 00 00 00 th: 82..........

 

 

00 00 02 ff 73 2d 2a ca 2f 52 30 31 30 b1 52 70 ....s-*./R010.Rp

 

 

f5 0a 70 f5 34 30 b0 b0 70 b5 52 08 c9 48 55 28 ..p.40..p.R..HU(

 

 

4a 2d ce 2f 2d 4a 4e 55 c8 cd 2d ce 54 48 ce 2f J-./-JNU..-.TH./

 

 

cd 49 51 c8 cb 2f 51 48 4a 55 48 cb 2f cd 4b d1 .IQ../QHJUH./.K.

 

 

e3 e5 02 00 1c 37 ac 4d 3e 00 00 00 .....7.M>...

 

 

---------------------------------------------------------------

 

 

Thanks!

6 Replies

  • Hi,

     

     

    So you're finding that after some period of everything working, a client will make an HTTP request to the VIP and they're not redirected to HTTPS by the LTM iRule. Instead they're sent to web servers which send a 404 response?

     

     

    Does that sound like a valid summary of the problem? If not, can you clarify?

     

     

    Thanks,

     

    Aaron
  • Hello Aaron,

     

     

    Thanks for the reply. Yes, after working for a period of time, all client connections will be redirected to a dynamic content stated above (/wps/contenthandler/...). When this occured, we have to failover to the standby unit and everything works. If we fail back to the trouble unit right away, the problem occured again unless we leave it long enough or restart the trouble unit.

     

     

    Thanks,

     

     

    WL

     

     

     

  • I think it would be easiest to open a case with F5 Support. I've never heard of a simple HTTP to HTTPS redirect rule ever failing--particularly only over time. They'll want to see a tech.out and tcpdumps of the failure.

     

     

    If you figure more out on this, could you reply back to clarify the issue?

     

     

    Thanks,

     

    Aaron
  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Is connection keepalive enabled or disabled on the HTTP (Port 80) server? Is the failing (404) response sent back from a new connection (First request) or a cached connection? (Second or subsequent request).

     

     

    What's this 'simple' redirection iRule look like?

     

     

    And if the port 80 VS is purely for redirecting to :443, why do you have poolmembers (Or even a pool) defined? (It's optional. And if you're never going to use it, don't have one to avoid leaks when/if your iRule doesn't work).

     

     

    H
  • Hello Aaron and H. Thanks for the replies. I don't have poolmembers defined on the http virtual server profiles. With the help of a F5 consultant, we are able to identify the issue (hopefully - so far no problem for almost 2 weeks). The consultant suggested us to clear all cache (from SSH) when the issue occured, as soon as we did that, everything back to normal. So we have disabled RAM cache for now.

     

     

    * When the RAM cache was on, we added "/wps/contenthandler" to the exclude list but that did not help.
  • Did you have RAM caching enabled on the HTTP VIP? You would definitely not want caching enabled if you're just redirecting all client requests to HTTPS. You could either use the unaltered default HTTP profile or create a custom HTTP profile with RAM caching disabled for the HTTP VIP.

     

     

    Aaron