Hi Scott, Robert, Thanks to both of you guys for helping me on this issue.
As both of you suggested, to consistently have a valid HTTP Header it is necessary to modify the ASSIGN statement to either use <@USERREFERENCECOOKIE> or enclose the <@SETCOOKIES> in an IF clause to only add the <@crlf> if the cookie is being set. The HTTP sniffer tool verifies all this. Thanks for both options, much appreciated. Mike. -----Original Message----- From: Scott Cadillac [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 01, 2007 2:24 PM To: [email protected] Subject: RE: Witango-Talk: Using assign with reqest$httpHeader Hi Mike, Yes, good point. When I used to use this stuff (years ago), I always used <@USERREFERENCECOOKIE> (spelling?) as the last part of the httpHeader assignment - which includes a <@CRLF> in the out. So, regardless if it was setting the UserReference session cookie on the first TAF request or not, your number of <@CRLF>'s will remain constant in the output (for the sake of the HTTP header). Of course I typically never set any custom cookies, which is why I could got away with it, so you could also try an <@IF> around the <@SETCOOKIE> to decide whether to include that extra <@CRLF>. Hope that helps, but I'm 4 timezones out of where I live, so take it for what's worth :-) Scott, On Wed, August 1, 2007 8:50 am, Mike Scally <[EMAIL PROTECTED]> said: > Scott/Robert, > > Thanks again for all the help. I had the <@purgeresults> just before the XML > output to remove any extra characters but its not helping and tried your > suggestions Robert. > > I have investigated a little further and using the header as follows (same as > before): > <@ASSIGN request$httpHeader "HTTP/1.1 <@HTTPSTATUSCODE> > <@HTTPREASONPHRASE><@crlf>Server: Witango <@version><@crlf>MIME-Version: > 1.0<@crlf>Content-Type: text/xml<@crlf><@SETCOOKIES><@crlf><@crlf>"> > > My question is <@SETCOOKIES> will only generate an entry in the HTTP Header > sometimes (depending on whether it receives a useereference in the request)? > Based > on this, if I start a new session and using the HTTP sniffer tool I see that > no > session cookie is sent to the browser, then my response is valid (as the > <@SETCOOKIES> creates an entry). > > However, if on the next request a userreference is sent as part of the > request, > the <@SETCOOKIES> part of the assign does not generate an entry in the HTTP > Header > - correct? If so, I end up with too many <@crlf>'s, as the <@SETCOOKIES> tag > generates no entry and hence we end up with 3 <@crlf> in a row. Does this make > sense or am I way off the mark here? > > Any insight much appreciated, > Mike. > > Just to sum up, making first request with no session cookie, response is as > follows: > HTTP/1.1 200 OK > Server: Microsoft-IIS/5.1 > Date: Wed, 01 Aug 2007 11:42:42 GMT > Connection: close > Server: Witango 5.5.003 Liquorice (Win32) > Content-Type: text/xml > Set-Cookie: Witango_UserReference=0B428628080572E646B071B1; path=/ > > ********XML starts here > > And on next request with usererference passed as part of request response is > as > follows: > HTTP/1.1 200 OK > Server: Microsoft-IIS/5.1 > Date: Wed, 01 Aug 2007 11:42:45 GMT > Connection: close > Server: Witango 5.5.003 Liquorice (Win32) > Content-Type: text/xml > > > ********XML Starts here (extra carriage return) > > > > -----Original Message----- > From: Scott Cadillac [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 01, 2007 5:06 AM > To: [email protected] > Subject: RE: Witango-Talk: Using assign with reqest$httpHeader > > Hi Mark, > > Sorry, I was having a brain fart earlier about the HTTP/1.1 thing (I'm jet > lagged). > > Robert has it right where you need to use <@PURGERESULTS> in a new Results > action > right before your xml output to help clean up any whitespace. > > Yes, some consumers of XML don't like leading carriage returns. So in your > case > there was 3 between your HTTP header and the content, where 2 is the delimiter > between a header and content. > > MSIE 6 uses a different XML interface than MSIE 7, so they interpretted the > input > differently. > > Scott, > > > > On Tue, July 31, 2007 12:13 pm, Mike Scally <[EMAIL PROTECTED]> said: > >> Hi Scott, >> >> Thanks for the response. When I remove the "HTTP/1.1" part of the header, I >> receive an error (500). Further investigation shows me that <@HTTPSTATUSCODE> >> <@HTTPREASONPHRASE> does not contain this information, even though I'm using >> version 5.5? >> >> However, the interesting thing is when I use fiddler, it also displays the >> extra >> carriage return character after the header and will not display the >> response as >> XML either. I have shown the first few lines of the response from fiddler >> below >> and it shows the extra carriage return. Not sure were it is coming from. >> >> Thanks, >> Mike. >> >> >> HTTP/1.1 200 OK >> Server: Microsoft-IIS/5.1 >> Date: Tue, 31 Jul 2007 15:08:11 GMT >> X-Powered-By: ASP.NET >> Connection: close >> Server: Witango 5.5.003 Liquorice (Win32) >> Content-Type: text/xml >> >> >> <!-- XML response started here.......notice 2 carriage returns above... >> >> -----Original Message----- >> From: Scott Cadillac [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, July 31, 2007 2:34 PM >> To: [email protected] >> Subject: RE: Witango-Talk: Using assign with reqest$httpHeader >> >> Hi Mike, >> >> Try removing the "HTTP/1.1 " at the begining of your assignment. The next two >> metatags are already providing that information (in eariler versions you had >> to >> do >> this, but not 5.5). >> >> Also, "MIME-Version: 1.0<@crlf>" is not necessary. >> >> A great tool for debugging this stuff is here >> http://www.fiddlertool.com/fiddler/. >> Install it, run it (no configuration required), then open IE and run your >> webpages >> and see the HTTP headers in action. Fiddle will even help point out the parts >> that >> are broken. >> >> Hope this helps. >> >> Scott, >> >> >> >> On Tue, July 31, 2007 7:31 am, Mike Scally <[EMAIL PROTECTED]> said: >> >>> Hi, >>> >>> >>> >>> I am working on Witango Server 5.5 and I have come across an issue with IE7. >>> Maybe >>> someone has either experienced this before or can point me in the right >>> direction >>> here. I am using the window.XMLHttpRequest object in the browser to retrieve >>> XML >>> content from the server. >>> >>> >>> >>> When retrieving the XML (pasted below) from the server the XMLRequest >>> objects >>> responseXML is empty in IE7 (i.e. it cannot load the XML thinking its not >>> valid). >>> However, on IE6 it gets populated with the XML as expected. It appears the >>> problem >>> is with using assign and request$httpHeader. >>> >>> >>> >>> I use >>> >>> <@ASSIGN request$httpHeader "HTTP/1.1 <@HTTPSTATUSCODE> <@HTTPREASONPHRASE> >>> <@crlf>Server: Witango <@version><@crlf>MIME-Version: >>> 1.0<@crlf>Content-Type: >>> text/xml<@crlf><@SETCOOKIES><@crlf><@crlf>">. >>> >>> When I check the XML received in the browser there is an extra return >>> character >>> (or some other similar character) at the start of the XML. >>> >>> >>> >>> When I remove the last <@crlf> from the assign and leave as follows : >>> >>> <@ASSIGN request$httpHeader "HTTP/1.1 <@HTTPSTATUSCODE> <@HTTPREASONPHRASE> >>> <@crlf>Server: Witango <@version><@crlf>MIME-Version: >>> 1.0<@crlf>Content-Type: >>> text/xml<@crlf><@SETCOOKIES><@crlf>"> there is no return character at the >>> start >>> of >>> the XML and the XML gets loaded in IE7. >>> >>> >>> >>> Would anyone have experienced this before? Obviously removing the >>> second<@crlf> >>> from the assign will solve the problem but is this creating an invalid >>> HttpHeader >>> despite the fact that IE doesn't complain? >>> >>> >>> >>> Thanks for any help, >>> >>> Mike. >>> >>> >>> >>> XML : >>> >>> >>> >>> <?xml version="1.0" encoding="ISO-8859-1" ?> >>> >>> <response> >>> >>> <method>reloadTabContents</method> >>> >>> <result> >>> >>> <scripthead>Test12345432</scripthead> >>> >>> <bodyresult>Test</bodyresult> >>> >>> </result> >>> >>> </response> >>> >>> >>> ________________________________________________________________________ >>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >> ________________________________________________________________________ >> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >> >> ________________________________________________________________________TO >> UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
