I haven't tested this, but I suspect that Cookies are sent in the
response header ONLY if they change. Could that be why you are
ending up with 3 line-breaks?
Bill
William M. Conlon, P.E., Ph.D.
To the Point
2330 Bryant Street
Palo Alto, CA 94301
vox: 650.327.2175 (direct)
fax: 650.329.8335
mobile: 650.906.9929
e-mail: mailto:[EMAIL PROTECTED]
web: http://www.tothept.com
On Aug 1, 2007, at 7:14 AM, Robert Garcia wrote:
Make sure that is your problem. Did you try it without set-cookies?
Does it work? Try my header, does it work consistently?
Then, I have used <@setcookies> before in a header, but I will have
to go find code to remember how I used it. But did you verify when
you used <@setcookies> that it behaved as you described? When we
developed our method, many moons ago, I am not sure why we chose
not to use <@setcookies>, but what we were doing we did not need
them. My suggestion to you, is don't use it, unless you really need
it (you probably don't), or like scott said, you can do
<@setcookies> yourself in a longer if statement.
--
Robert Garcia
President - BigHead Technology
VP Application Development - eventpix.com
13653 West Park Dr
Magalia, Ca 95954
ph: 530.645.4040 x222 fax: 530.645.4040
[EMAIL PROTECTED] - [EMAIL PROTECTED]
http://bighead.net/ - http://eventpix.com/
On Aug 1, 2007, at 4:50 AM, Mike Scally wrote:
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
õõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõõ
õõõõDòTå5T%45$”$S¢vòFò‡GG¢ò÷wwrçv—Fævòæ6öÒöFWfVÆ÷W"öÖ–ÆÆ—
7BçF`
______________________________________________________________________
__
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
