This content has been marked as final. Show 5 replies
I would assume you are using the WE HTTP library (not HTTPSupport), if so HTTPMessage bears two attributes that may be of interest to you:
normally ExtensionHeader contains all the extra stuff aside (Allow, Content-Encoding, Content-Language, Content-Length, Content-Location, Content-MD5, Content-Range, Content-Type, Expires & Last-Modified) e.g. things that do not fit in the HTTP/1.1 (RFC ???)
ExtensionHeader would propably have the extra bit of info the SiteMinder may add to the header.
That's my best bet, but I don't know the modus operandi of SiteMinder, run the stuff thru the debugger or dump the contents of (ContentBase/ExtensionHeader) to a file or stdout
Hope this helps,
Thanks for your reply, but when I log the contents of the ExtensionHeader and ContentBase attributes they appear empty. I have also identifed another attribute on HTTPRequest - CustomHeaders, but it also is unpopulated.
Do you know if there is any way to force these to be populated e.g. a flag that should be set?
Or do you know of any way to convert a HTTPRequest object into a HTTPBaseRequest object that does appear to support apis to retrieve http headers?
Thanks for your help.
I had forgotten how a pain it was to attache the debugger to the proper process and I should have read the HTTP/1.1 RFC ... (http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html)
anyway, the request header can be accessed through the qqwe_Buf attribute on the HTTPRequest class. In fact it contains the full request.
In your HandleTemplateRequest or HandleRequest overidden method if you dump the contents with a bit of code like this
myStr : TextData = new();
may be you'll need to restore the Offset to its previous value.
that should get you something similar to this:
Cookie: ShopCartService=091E1A7B24251E2422241B2D17012674; frte_lbf_ShopCartServi
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:220.127.116.11) Gecko/2
Hope this helps.
Apologies for misleading you in me previous post.
PS: HTTPSupport is meant to use UDS as a "web-server" I tried to instantiate a HTTPBaseRequest and stuff the query attribute with the contents of qqwe_Buf and poke around to initialize the stuff but I haven't managed to get anything out of it (there must be a lot of things done behind the scenes).
Thanks very much for your reply - when I logged the contents of the qqwe_Buf attribute I was able to find the user name (that had been placed in a http header by SiteMinder). But the value wasn't placed in the SiteMinder header named sm_user, but associated with WebEnterprise.RemoteUser. The other headers created by SiteMinder were not present. Do you know if Forte discards all the other headers it doesn't recognise? Does it just strip out ones it recognises and associates them with WebEnterprise.*? Also, do you know what the intended use of the qqwe_Buf attribute is? Do you think it would be safe to rely on it being populated?
Thanks for your help again.
K3wl, the qq**_Stuff is Fort� internal and I'd say it can be trusted. Then again it may change from one major version to another (but that's may be not the main concern).
If you don't mind me asking what Fort� version are you using. And if you've got a version of SiteMinder (Win or Solaris) that you can share ... send me an email on me profile's address.
To see what is coming in, snoop on the connection between the two hosts (web server and SiteMinder).
Use tcpdump or snoop on UNIX and (http://www.winpcap.org/) on Windows you need admin rights but you may be able to snoop on two remote hosts if the network is not switched.
and compare the dumps with what you get within Fort�.
If Fort� is dropping fields, or portions of the Header, I'd say the only way then would be to attach a debugger to see where it's happening and if it can be retrieved with a raw pointer in Fort� ... always possible to manipulate the pointee.
Have a G'Day.