Tim-Thanks for the comprehensive explanationI found this link helpful for CICS
transactions
http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=/com.ibm.cics.ts31.doc/dfhtl/topics/dfhtl_http11serverintro.htm
do you need IIS running..is there a way to perhaps use Apache with mod_jk just
to ensure http-1.1 <chunked encoding/content-length> bilateral connections are
supported?
Then once all your staging environments are operational then sub in IIS with
all those mysterious dlls?
Martin ______________________________________________Disclaimer and
confidentiality noteEverything in this e-mail and any attachments relates to
the official business of Sender. This transmission is of a confidential nature
and Sender does not endorse distribution to any party other than intended
recipient. Sender does not necessarily endorse content contained within this
transmission.> From: [EMAIL PROTECTED]> To: users@tomcat.apache.org> Subject:
RE: Content_Length Problem> Date: Sat, 5 Jan 2008 22:41:31 +1300> > From what I
can tell there's nothing (technically) wrong with what Tomcat> + ISAPI
Redirector is doing here.> > What's actually happening here is that Tomcat
internally only provides a> Content-Length header if it can determine the
length of the content easily> (e.g. it's a static file) or the Servlet
generating dynamic content> provides one itself.> Any other response content is
just written out to whatever connector> (HTTP/AJP) is being used. If it's via
the HTTP connector, then chunk> encoding is automatically provided. Likewise
with the AJP connector and> mod_jk in Apache - chunk encoding is automatically
provided by Apache for> all responses that would benefit from it (mod_jk
doesn't do anything> special to achieve this).> IIS being the braindead poor
cousin is not so accomodating, as it requires> any ISAPI extension to not only
tell it that it would like to use> persistent HTTP connections, but also
provide all of the HTTP level> details (including headers and content encoding)
to make it work. All IIS> does is detect if you've done enough to make the
connection persistent and> keep open/close the connection if you haven't.>
Since the current ISAPI redirector doesn't implement chunk encoding, IIS>
whacks in a Connection: close header on all responses without> Content-Length
and closes the connection to the client.> > Closing the connection is actually
a valid method of terminating a> response message in HTTP 1.1 (as Rainer
alluded to, the statement> attributed to IBM below about a Content-Length being
required in HTTP 1.1> is wrong in a lot of ways - indeed in some responses
Content-Length must> not be included).>
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 and>
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.10 seem to be>
pretty clear on how an HTTP application that doesn't support persistent>
connections should behave - what IIS + ISAPI Redirector is doing is (from> what
I can tell) valid HTTP 1.1, it's just not polite in this day and age.> > The
fact that your web service call works when accessing Tomcat directly> via the
HTTP connector implies that the client can handle chunk encoded> responses,
since the Tomcat HTTP connector provides this for anything that> doesn't have a
Content-Length set, and your logs indicate your web app> isn't setting one. I
might have missed some magic Content-Length> calculation for small responses in
the Tomcat HTTP connector, but I'd> imagine that wouldn't work in all cases
(e.g if you had a really large> response message).> You could test this theory
by sniffing the network traffic when connecting> directly to Tomcat, by
installing Apache + mod_jk, or by using my patched> IIS connector from
http://sourceforge.net/projects/timsjk (the latter two> options will provide
chunked encoding on all responses coming from Tomcat> that don't already
provide a Content-Length.> (btw I'd be very surprised if my chunked encoding
patch attached to the BZ> issue worked, as it hasn't been updated to trunk for
quite a while.> http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1
states that> HTTP 1.1 applications must be able to receive chunk encoded
responses so> if adherence to HTTP 1.1 is important in your environment, you
should be> able to argue that this is a valid solution.> > Other more desperate
options would involve content buffering Servlet> Filters that wrap the response
to calculate and set the Content-Length> headers (there were a couple floating
around the Tomcat world a while> back) and hacking your web service toolkit to
buffer messages pre sending> and set the Content-Length header. I've used the
filter approach in the> past (pre HTTP 1.1), and it might be workable as long
as your web services> responses have predictably and reasonably small content
sizes.> > cheers> tim> > -----Original Message-----> From: Woytasik Joe
[mailto:[EMAIL PROTECTED] > Sent: Saturday, 5 January 2008 10:10 a.m.> To:
Tomcat Users List> Subject: RE: Content_Length Problem> > Rainer,> > Thanks for
the quick response! > > I am able to repeat this request, and each time I get
the same response.> The logging level is set to debug, but unfortunately I am
unable to send> the log file (company policy). I am going to scrub the log file
to remove> any sensitive information, I will send that your way shortly.> > I
did some network sniffing and CONTENT_LENGTH is not sent. > > I built a new
isapi_redirect.dll using the patch provided in Bugzilla.> This patch was
supposed to allow chunked encoding, but I am not sure if I> applied it right.
Is there a registry setting that I need to change to> allow chunked encoding
with this patch, or does it do it automatically?> > Thanks-> Joe > >
-----Original Message-----> From: Rainer Jung [mailto:[EMAIL PROTECTED]> Sent:
Friday, January 04, 2008 2:06 PM> To: Tomcat Users List> Subject: Re:
Content_Length Problem> > Hi Joe,> > are you able to reproduce the behaviour
with few, maybe only a single> request? If so: you can increase JkLogLevel to
"debug" (not recommended> for high load production size, because it produces a
lot of log lines),> reproduce the problem and make the log file available.> >
What I didn't really understand from your post: do you know, if the>
Content-Length header gets send or not? How do you know? Did you sniff the>
network traffic or do you only know from the CICS behaviour?> > Lastly:
HTTP/1.1 responses without Content-Length headers are valid if> they are using
chunked encoding (Transfer-Encoding: chunked). I think at> the moment the isapi
redirector does not use chunked encoding (didn't yet> test, but there's an open
RFE to implement chunked encoding in the isapi> redirecotr), but I want to
clarify the absolute statement concerning the> http protocol.> > Chunked
encoding replaces the content-length header with sending the> number of bytes
available in front of every chunk, s.t. the receiving node> knows, how much
data to expect, without the sending node needing to know> the full size before
sending. Dynamically generated content often uses> chunked encoding to prevent
the need of buffering the whole reposne before> sending.> > Regards,> > Rainer>
> > Woytasik Joe schrieb:> > I have a custom webservice hosted on IIS 6.0 and
Tomcat 6, and I am > > using the latest version of the isapi_redirect.dll. The
problem > > occurs when a CICS mainframe application tries to call this>
webservice.> > Everything appears to work fine, but the CICS application
receives a > > response indicating a zero length message. I can view the
message > > being sent from the webservice and this is definitely not the case
> > (have also taken several packet traces to confirm this). We sent our > >
problem to the folks over at IBM and they say that the CONTENT_LENGTH > > is
not being set.> > > > Here is their response: > > > > The problem is that there
isn't a Content-Length header sent by the > > IIS/Tomcat Server. CICS receives
the headers and finds it is an> > HTTP/1.1 response for a Connection: Close.
There isn't a > > Content-Length header so there can't be any user data
(HTTP/1.1 has to> > > supply Content-Length) so DFHWBCL just closes the
session. PI domain > > then indicates that it failed to receive a response. The
customer > > needs to investigate why their IIS server didn't return a > >
Content-Length header.> > . > > The Content-Length header is mandatory for
CICS' HTTP/1.1 > > conversations. This is documented in the CICS/TS 3.1
Internet Guide, > > section 1.3.11.1 ("CICS Web support behavior in compliance
with > > HTTP/1.1"); this chapter documents the requirement in a section
titled> > > "New Behavior for CICS TS Version 3", under the first item "CICS >
> checks inbound messages for compliance with HTTP/1.1, and handles or > >
rejects non-compliant messages":> > Note: CICS requires the Content-Length
header on all inbound> > HTTP/1.1 messages that have a message body. If a
message body is > > present but the header is not provided, or its value is
inaccurate, > > the socket receive for the faulty message or for a subsequent
message > > can produce unpredictable results. For HTTP/1.0 messages that have
a > > message body, the Content-Length header is optional.> > . > > The reason
this is mandatory under CICS/TS 3.1, is due to our > > adherance to HTTP/1.1
specifications -- in other words, your HTTP/1.1 > > Web Service PROVIDER
platform must provide this header, to be> considered compliant.> > . > > Please
ensure the IIS/Tomcat server sends a proper header.> > > > If we make the same
request directly to Tomcat using the port number > > it works fine. The problem
either lies in the isapi_redirect.dll or > > the IIS configuration. Does anyone
have any ideas on what I can try > > to resolve this? Is there a know bug with
the isapi_redirect.dll and > > CONTENT_LENGTH?> > > > Thanks-> > Joe> > > >
This e-mail is confidential. If you are not the intended recipient,> you must
not disclose or use the information contained in it. If you have> received this
e-mail in error, please tell us immediately by return e-mail> to [EMAIL
PROTECTED] and delete the document.> > > > E-mails containing unprofessional,
discourteous or offensive remarks> violate Sentry policy. You may report
employee violations by forwarding> the message to [EMAIL PROTECTED]> > > > No
recipient may use the information in this e-mail in violation of> any civil or
criminal statute. Sentry disclaims all liability for any> unauthorized uses of
this e-mail or its contents.> > > > This e-mail constitutes neither an offer
nor an acceptance of any> offer. No contract may be entered into by a Sentry
employee without> express approval from an authorized Sentry manager.> > > >
Warning: Computer viruses can be transmitted via e-mail. Sentry> accepts no
liability or responsibility for any damage caused by any virus> transmitted
with this e-mail.> >
---------------------------------------------------------------------> To start
a new topic, e-mail: users@tomcat.apache.org To unsubscribe,> e-mail: [EMAIL
PROTECTED]> For additional commands, e-mail: [EMAIL PROTECTED]> > >
---------------------------------------------------------------------> To start
a new topic, e-mail: users@tomcat.apache.org To unsubscribe,> e-mail: [EMAIL
PROTECTED]> For additional commands, e-mail: [EMAIL PROTECTED]> > > >
---------------------------------------------------------------------> To start
a new topic, e-mail: users@tomcat.apache.org> To unsubscribe, e-mail: [EMAIL
PROTECTED]> For additional commands, e-mail: [EMAIL PROTECTED]>
_________________________________________________________________
Share life as it happens with the new Windows Live.
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008
