| Author |
Message
|
| PeterPotkay |
 Posted: Wed Oct 31, 2007 11:52 am Post subject: How to code to override an http response header parameter |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Hi. One of the developers at my company had the following question:
| Quote: |
I have a message flow that is http input to a mainframe service and back. The requesting application is setting the http connection to Keep-Alive and I am trying to override it by setting the connection to 'close' prior to the http reply node.
I have it coded like this:
| Code: |
| SET OutputRoot.HTTPResponseHeader.Connection = 'close'; |
But this is being ignored.
What is the correct way to code this? |
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Oct 31, 2007 12:01 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I think it needs to be "HTTPReplyHeader"...
But it may already be too late at this point to keep the connection from closing.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Nov 01, 2007 8:53 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
What I am trying to do is to get the connection to close, not prevent it from closing. The sending application seems to be waiting on the connection,,, I'm trying to override connection = Keep-Alive with connection = close.
I tried the HTTPReplyHeader but that didn't do it - I also tried to uncheck the Generate default HTTP headers from input or response on the HTTP Reply node, but that didn't change anything either.
Thx!
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Nov 01, 2007 9:05 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Aha.
Well, it does need to be HTTPReplyHeader. And the checkbox does need to be unchecked on the Reply node.
I'm still not sure that it's going to be possible to affect the sending application 's use of the connection this way. This header tends to be on the request, not on the reply.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Nov 01, 2007 9:36 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Turns out the original code was working as desired. There was an old copy of the flow in another EG. Once that was stopped and removed the newly coded flow worked as designed.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mgk |
| Posted: Thu Nov 01, 2007 12:16 pm Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
The old code works because the Reply node "merges" all headers from
HTTPResponseHeader and HTTPReplyHeader parsers. Normally an HTTPRequest node would create any HTTPResponseHeader you see in a flow - the HTTPReplyHeader is there to allow users to set headers for the reply. So although you can use a response header for this, Jeff is correct in saying to use an HTTPReplyHeader, as any headers in a Reply header take precedence over headers of the same name in a Response header. So from an "maintenance" point of view it is better to use a Rely header for this if you can.
Cheers,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
|
|
