Hi Oleg!

After sending the mail, I started to question my design myself. Of course, my
application stuff has nothing to do with the HTTP transport. Chunked encoding is
(as you say) a TRANSFER encoding, which an application should have NO knowledge
of the internal workings of. To make some application logic dependant on the
inner workings of the transport protocol is, to be polite, not so good :-).

Now, the client sends a request asking if something has changed, if so it will
be notified immediately otherwise the response-channel will be kept alive until
a notification is due.


Sorry for taking up your time with my rather 'stupid' design.

Regards

/Fredrik



|--------+------------------------------------>
|        |          "Kalnichevski, Oleg"      |
|        |          <[EMAIL PROTECTED]|
|        |          point.com>                |
|        |                                    |
|        |          2003-03-13 15:06          |
|        |          Please respond to "Commons|
|        |          HttpClient Project"       |
|        |                                    |
|--------+------------------------------------>
  >----------------------------------------------------------------------------|
  |                                                                            |
  |      To:     "Commons HttpClient Project"                                  |
  |       <[EMAIL PROTECTED]>                          |
  |      cc:     (bcc: Fredrik Herbertsson/OMT/OMGROUP)                        |
  |      Subject:     RE: How to get access to individual chunks in chunked    |
  |       response?                                                            |
  >----------------------------------------------------------------------------|




Fredrik,

We have striven to make transfer encoding absolutely transparent to the client.
We have never envisaged direct access to individual chunks of chunk-encoded
data.

I may be wrong here, but let me express my personal opinion on this matter.
Please bear in mind HTTP protocol has been designed to be stateless,
request/response oriented (with cookies being a very clumsy attempt at adding
session persistence later on). I doubt that HTTP protocol is well suited for
implementing any sort of notification channel. I suggest you reconsider your
design and probably use good ol' polling instead, rather than getting very
creative with the use of chunk encoding

Cheers

Oleg

-----Original Message-----
From: Fredrik Herbertsson [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 13. M�rz 2003 13:27
To: [EMAIL PROTECTED]
Subject: How to get access to individual chunks in chunked response?




HI,

Is it possible using HttpClient to get access to individual chunks in an chunked
response?
Further, does the HTTP standard allow a HTTP-server to send MORE than one (full,
i.e. last chunk of size 0 sent) HTTP/1.1 200 responses for one request?

The problem I'm trying to solve is to make a request on a particular connection,
get a response (including data I need. In my case an application session id) and
then further wait for an application notification. The mentioned connection is a
notification channel used to notify client when certain application events
occur.

 I've been looking at the source for the ChunkedInputStream and as far as I can
see it is not possible to get hold of the chunks. (As it probably shouldn't be
since the stream is supposed to abstract stuff like that away :-). I only seem
ta have access to the full response. Is it possible to receive another (chunked)
response on the used InputStream? I't looks that the EOF flag is set when the
Last-Chunk is received and successive calls to read will immediately return -1,
making the stream useless for further responses. Is it possible to re-use the
connection (underlying Socket) and get a stream that reads from the same
underlying connection?

... or do I have to use 'raw' sockets on the client-side and parse the response
including the HTTP stuff :-(

Regards
/Fredrik Herbertsson



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to