Problem with HttpOnly Cookie

, ,
1

Hi All,

we have a customer who wants to send ebXML over HTTP.
However this fails.

He gets the error

No '=' found for token starting at position 48

after getting our HTTP response (sniffed HTTP traffic on customer side):

HTTP/1.1 500 OK
Date: Thu, 27 Aug 2009 15:00:21 GMT
Content-Type: text/xml
Content-Length: 1059
[B]Set-Cookie: ssnid=317bc000931a11de8e518db04e3e3dbf; path=/; HttpOnly[/b]
Via: 1.1 server.xyz.com
Connection: close

Now, position 48 is the postion where the HttpOnly starts. Since it does not have a “value” (name=value), the software at the customer’s side runs into an error. And we do not get the data we want.

Is there a possibility in the IS to turn this HttpOnly flag off?
(As I learned, The HttpOnly flag is not part of any standard, and is not implemented in all browsers, so we could maybe turn it off without any problem?!)

Cheers,
fcctr

2

Unfortunately this seems to be hard-coded (meaning no config parameter available to change the behaviour). But fortunately the “Set-Cookie” header field is added to the Response Header, BEFORE the execution of the requested Flow Service is started. (I assume, your customer posts his XML to one of your Flows, which processes the data and returns the response!?)

In that case we can modify the “Set-Cookie” header from inside our Flow: just create a Java Service with the following code:


HttpHeader rspHeader = Service.getHttpResponseHeader(new Values());
String cookie = rspHeader.getFieldValue("Set-Cookie");
if (cookie != null)
	rspHeader.setField("Set-Cookie", cookie.substring(0, cookie.lastIndexOf(' ')));

(You need to add the following line in the “Imports” section of the Java Service:
com.wm.net.HttpHeader
)

and add it as the last step of your Flow. It reads the current value of the “Set-Cookie” header, truncates the “HttpOnly” at the end of the string and then sets it as the new value of “Set-Cookie”.

However, instead of doing the above, you may also ask your customer to update his HTTP client program to accept that token, because it is there for a reason: it makes cross-site scripting a little bit harder. See http://www.codinghorror.com/blog/archives/001167.html

Lanzelot