Scrive Arno Garrels <[EMAIL PROTECTED]>:
> Maurizio Lotauro wrote:
> > It seems quite easy and without drawback because reproduce the
> > "normal" flow. What do you think?
>
> Updated both ICSv6 and ICSv7 SVN repository.
Thank you very much!
For record, I posted a message to the Tomcat mailing
Maurizio Lotauro wrote:
> It seems quite easy and without drawback because reproduce the
> "normal" flow. What do you think?
Updated both ICSv6 and ICSv7 SVN repository.
--
Arno
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailma
Scrive Arno Garrels <[EMAIL PROTECTED]>:
> Maurizio Lotauro wrote:
>
> > I added a new internal variable FDelaySetReady (boolean) as flag that
> > the SetReady must be called when the whole SendStream is sent.
> > Some places changed so:
> >
> > =>else if ((FStatusCode = 401) or (FS
Maurizio Lotauro wrote:
> I added a new internal variable FDelaySetReady (boolean) as flag that
> the SetReady must be called when the whole SendStream is sent.
> Some places changed so:
>
> =>else if ((FStatusCode = 401) or (FStatusCode = 407)) and
> =>FAllowedTo
Scrive Arno Garrels <[EMAIL PROTECTED]>:
> Maurizio Lotauro wrote:
[...]
> > Arno, I'll try to add these changes to the version you send me so you
> > can give it a try.
>
> Will do. Unfortunately my very old proxy machine that I used to test
> NTLM proxy authentication went into the trash bin
Maurizio Lotauro wrote:
> It seems quite easy and without drawback because reproduce the
> "normal" flow. What do you think?
Sounds reasonable.
> Arno, I'll try to add these changes to the version you send me so you
> can give it a try.
Will do. Unfortunately my very old proxy machine that I us
Scrive Arno Garrels <[EMAIL PROTECTED]>:
> Maurizio Lotauro wrote:
[...]
> > Unfortunately I'm still using an old version of HttpProt.pas (1.86),
> > and it seems different from yours, at least in the StateChange
> > procedure. Can you send your HttpProt.pas?
>
> It's from Icsv7 but the snippet
Scrive "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
[...]
> I'm sorry but I'm confused. What caused IE to open a
> new connection? When you say "I confirm", do you
> mean that you submit a username and password when IE
> prompted you?
Consider that English is not my native language (not to mention
Maurizio Lotauro wrote:
> Scrive Arno Garrels <[EMAIL PROTECTED]>:
>
>> DZ-Jay wrote:
>>
>>> we should try to replicate the behaviour in HttpCli: perhaps adding
>>> a new machine state that instead of re-sending when 401 is
>>> detected, it makes sure that the body has been sent completely, and
>
Scrive Arno Garrels <[EMAIL PROTECTED]>:
> DZ-Jay wrote:
>
> > we should try to replicate the behaviour in HttpCli: perhaps adding a
> > new machine state that instead of re-sending when 401 is detected, it
> > makes sure that the body has been sent completely, and if not, it
> > delays re-sendin
QUOTE:
I not convinced of this. The title of the section is
"Monitoring Connections for
Error Status Messages". So when it say "SHOULD
monitor the network connection
for an error status" I think that it refers to the
connection itself and not to
an error reported by the server.
Wow, you
Scrive "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
[...]
> Yes, section 8.2.2 says:
[...]
> As I mentioned in my previous message, I believe that
> this requirement is because the server responded
> early for a reason: it rejected the request, so
> sending the rest of the body to satisfy the
> Con
I must apologize for the bizarre and annoying quoting and wrapping in
some of my posts. When I respond from work I have no access to an SMTP
server, so I must use my ISP's atrocious Web Mail system which
hard-wraps everything at 76 characters (without Quoted-Printable
soft-wraps) and distorts
QUOTE:
> Yes, but the response came while the body was in
> transit already, before it was sent completely, which
> puts the transaction in a very unstable state. This
> is the reason why the RFC requires the client (i.e.
> it says it "MUST") close the connection if the
> Content-Length heade
Scrive "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
> Hello:
> I'm sorry for the long discussions, but we have
> identified an issue and understanding each other is
> the only way to work together to solve it. Please
> read below for my responses.
I think that putting together our experience i
DZ-Jay wrote:
> we should try to replicate the behaviour in HttpCli: perhaps adding a
> new machine state that instead of re-sending when 401 is detected, it
> makes sure that the body has been sent completely, and if not, it
> delays re-sending until it does.
My attempt below works with the link
DZ-Jay wrote:
>> It works when you send all data in FSendStream from event
>> THttpCli.SocketDataSent at once. That's of course not a real fix but
>> it works, give it a trial.
>
> This works because it prevents the HttpCli from acknowledging the 401
> response until after it finishes sending (am
On Sep 23, 2008, at 21:34, Maurizio Lotauro wrote:
> The problem is that when HttpCli detect the 401 (after finished to
> receive the
> body?) it start to re-send even if it has not finished the previous
> one, so the
> server will discard part of it, so it appear "truncated" on the head.
I'm
Maurizio Lotauro wrote:
> The problem is that when HttpCli detect the 401 (after finished to
> receive the body?) it start to re-send even if it has not finished
> the previous one, so the server will discard part of it, so it appear
> "truncated" on the head.
That's exactly what I found today a
Scrive "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
> Ok, that makes more sense. And, just to make sure I
> understand, here's the sequence of events:
>
> 1. IE Sends request without auth information.
Yes
> 2. Server responds with 401 after the headers are
> received.
Yes
> 3. IE continues sendi
Scrive "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
> Maurizio,
>
> Is this test server the Tomcat server where the issue
> manifested before?
Yes, only the servlet is different. I asked for a minimum version to do not have
other thinks that can affect the test. This one simply count the bytes recei
ntent-Length data and the server is
interpreting the extraneous data as a new request.
-dZ.
>--- Original Message ---
>From: Arno Garrels[mailto:[EMAIL PROTECTED]
>Sent: 9/23/2008 3:04:54 PM
>To : twsocket@elists.org
>Cc :
>Subject : RE: Re: [tws
[EMAIL PROTECTED] wrote:
> So, if I understand correctly, part of the body was
> sent after the 401 response (that which was in the
> send buffer already), and the remainder was sent
> after the authentication header was sent?
My mistake, there are too many packets in the log.
Actually IE resends
Arno Garrels wrote:
> 3) IE then sends just the header with the credentials and continues
> posting the rest of the data.
:-) Should read "IE then sends just the header with credentials and continues
posting remaining data."
--
Arno
--
To unsubscribe or change your settings for TWSocket mailing
-authenticated request. This smells like a
security vulnerability. Or am I misunderstanding it?
-dZ.
>--- Original Message ---
>From: Arno Garrels[mailto:[EMAIL PROTECTED]
>Sent: 9/23/2008 2:25:24 PM
>To : twsocket@elists.org
>Cc :
>Subject : RE: Re: [t
Maurizio Lotauro wrote:
> I have a public server that show the problem. Who is interested write
> me an email.
IE and your server act like this:
1) IE starts sending - server sends acts.
2) After some packets have been sent and acknowledged the 401 response
is received and IE paused sending an
27;t really test this at the moment.
-dZ.
>--- Original Message ---
>From: Maurizio
Lotauro[mailto:[EMAIL PROTECTED]
>Sent: 9/23/2008 12:32:24 PM
>To : twsocket@elists.org
>Cc :
>Subject : RE: Re: [twsocket] Early web server response
>
>Scrive Mau
Hello:
I'm sorry for the long discussions, but we have
identified an issue and understanding each other is
the only way to work together to solve it. Please
read below for my responses.
I would take this off-list, except for the fact that
it is a discussion on the implementation o
Scrive Maurizio Lotauro <[EMAIL PROTECTED]>:
> Scrive DZ-Jay <[EMAIL PROTECTED]>:
[...]
> > In any case, I'll see if I can do some experiments with IE and Tomcat
> > and let you know what I find.
>
> Please wait, I asked to our server admin to prepare a test environment
> public
> available (I
Scrive DZ-Jay <[EMAIL PROTECTED]>:
> On Sep 21, 2008, at 18:53, Maurizio Lotauro wrote:
[...]
> I'm sorry but you are confused. HTTP is not like FTP.
I mentioned ftp only as example that show how many time is needed to make the
connection, while http do it behind the scene.
> In HTTP 1.1,
>
Scrive DZ-Jay <[EMAIL PROTECTED]>:
[...]
I'll answer asap (probably this night).
> In any case, I'll see if I can do some experiments with IE and Tomcat
> and let you know what I find.
Please wait, I asked to our server admin to prepare a test environment public
available (I need it for myself
>> DZ-Jay said...
>> coercing HTTP as the de facto standard protocol for all communications in
the Internet (as a lot of people are trying to make it) is stupid. There
are better transfer protocols out there.
Preach it! The Commodore 64 implemented better protocols... ;)
>> But this is a ran
On Sep 21, 2008, at 18:53, Maurizio Lotauro wrote:
> HTTP is stateless, but this has nothing to do with keeping the
> connection open.
> I don't think that a browser reopen the connection for every part that
> compose a
> web page.
> And I don't think also that you close and reopen the connection
Scrive DZ-Jay <[EMAIL PROTECTED]>:
>
> On Sep 20, 2008, at 19:03, Maurizio Lotauro wrote:
>
> > I just saw it. The 401 become after the whole file is sent.
>
> Leave it to MS to allow for a DOS attack vector, ha!
:-)
> As Maurizio said, we need to test this on a server that responds after
>
On Sep 20, 2008, at 19:03, Maurizio Lotauro wrote:
> I just saw it. The 401 become after the whole file is sent.
Leave it to MS to allow for a DOS attack vector, ha!
As Maurizio said, we need to test this on a server that responds after
the headers are sent (before the payload).
> It's IE try
Scrive Arno Garrels <[EMAIL PROTECTED]>:
> Arno Garrels wrote:
[...]
> > I've uploaded a Wireshark dump file:
> > http://www.duodata.de/misc/PostAuthLog.zip
[...]
> Well, it does not show the case we are are discussing here.
I just saw it. The 401 become after the whole file is sent.
But AFAI
Arno Garrels wrote:
> Maurizio Lotauro wrote:
>> Scrive "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
>>
>> [...]
>>
>>> However, I wonder how this works in practice. I
>>> mean, how do regular browsers deal with it?
>>
>> Good question. Someone that know the html can prepare a page with a
>> text b
Maurizio Lotauro wrote:
> Scrive "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
>
> [...]
>
>> However, I wonder how this works in practice. I
>> mean, how do regular browsers deal with it?
>
> Good question. Someone that know the html can prepare a page with a
> text box where write the content to s
Scrive "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
[...]
> However, I wonder how this works in practice. I
> mean, how do regular browsers deal with it?
Good question. Someone that know the html can prepare a page with a text box
where write the content to send and a post button?
It will be very u
Scrive "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
[...]
> Again, I must be missing something (I admit I am not
> very familiar with NTLM authentication).
As Fastream already wrote, the server send a (sort of?) token with the 401
answer. You car read more info there:
http://davenport.sourceforge.n
Scrive Arno Garrels <[EMAIL PROTECTED]>:
> Maurizio Lotauro wrote:
> > This will work with Basic bu not with NTLM because (IIRC) the
> > authentication phase is started by the server with the first 401.
>
> Looks like sending body data must be delayed somehow, realy not
> nice!
I don't think so,
emphasis) drop the connection.
Perhaps it's done with "chunking"?
-dZ.
>--- Original Message ---
>From: Fastream
Technologies[mailto:[EMAIL PROTECTED]
>Sent: 9/19/2008 12:54:58 PM
>To : twsocket@elists.org
>Cc :
>Subject : RE
On Fri, Sep 19, 2008 at 7:45 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >--- Original Message ---
> >From: Maurizio
> Lotauro[mailto:[EMAIL PROTECTED]
> >Sent: 9/19/2008 11:24:14 AM
> >To : twsocket@elists.org
> >Cc :
&g
>--- Original Message ---
>From: Maurizio
Lotauro[mailto:[EMAIL PROTECTED]
>Sent: 9/19/2008 11:24:14 AM
>To : twsocket@elists.org
>Cc :
>Subject : RE: Re: [twsocket] Early web server response
>
> This will work with Basic bu not with N
Maurizio Lotauro wrote:
> This will work with Basic bu not with NTLM because (IIRC) the
> authentication phase is started by the server with the first 401.
Looks like sending body data must be delayed somehow, realy not
nice!
Maybe OnSendBegin is the right place:
THttpCli.SocketSessionConnected(
Scrive "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
> >--- Original Message ---
> >From: Maurizio
> Lotauro[mailto:[EMAIL PROTECTED]
> >Sent: 9/19/2008 10:25:03 AM
> >To : twsocket@elists.org
> >Cc :
> >Subject : RE: Re
>--- Original Message ---
>From: Maurizio
Lotauro[mailto:[EMAIL PROTECTED]
>Sent: 9/19/2008 10:25:03 AM
>To : twsocket@elists.org
>Cc :
>Subject : RE: Re: [twsocket] Early web server response
>
> I cannot close the connection, it will not
> wo
Scrive "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
> >--- Original Message ---
> >From: Maurizio
> Lotauro[mailto:[EMAIL PROTECTED]
> >Sent: 9/19/2008 8:12:30 AM
> >To : twsocket@elists.org
> >Cc :
> >Subject : RE: Re:
>--- Original Message ---
>From: Maurizio
Lotauro[mailto:[EMAIL PROTECTED]
>Sent: 9/19/2008 8:12:30 AM
>To : twsocket@elists.org
>Cc :
>Subject : RE: Re: [twsocket] Early web server response
>
> How I can avoid the second chunk or tell the server
Scrive Maurizio Lotauro <[EMAIL PROTECTED]>:
> Scrive Arno Garrels <[EMAIL PROTECTED]>:
>
> > Maurizio Lotauro wrote:
[...]
> > Looking into THttpCli.SocketDataAvailable, OnDataPush seems to be
> > triggered in this case. LastResponse should the contain 401/407,
> > possibly you handle this ca
Scrive Arno Garrels <[EMAIL PROTECTED]>:
> Maurizio Lotauro wrote:
>
> > I analyzed the communication using WireShark and this is what I
> > observed.
> > The server answer with 401 before the client has finished to send the
> > xml. The client continue to send the rest of xml,
>
> Looking in
Maurizio Lotauro wrote:
> I analyzed the communication using WireShark and this is what I
> observed.
> The server answer with 401 before the client has finished to send the
> xml. The client continue to send the rest of xml,
Looking into THttpCli.SocketDataAvailable, OnDataPush seems to be
t
Scrive Maurizio Lotauro <[EMAIL PROTECTED]>:
[...]
> This night I'll check if the component catch the 401. If yes then I'll try
> to
> "abort" the transmission. If no then we have a problem...
Bad news. It seems that the HttpCli doesn't feel the 401. Even the 414 become
before the end of client
Scrive "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
[...]
> Perhaps we can implement something like this?
My custom HttpCli has a retry mechanism. It is very simple, based only on the
number of retry. I added it because sometimes the server take to much time to
answer, and it is a problem for me
Scrive Arno Garrels <[EMAIL PROTECTED]>:
[...]
> I may be wrong, however I think I recall that the THTTPCli sent entire
> POST-data even though authentication was what the server expected.
This exactly what happen.
> That sounds, at least, not very efficient and the server might treat this
>
>--- Original Message ---
>From: Arno Garrels[mailto:[EMAIL PROTECTED]
>Sent: 9/17/2008 2:09:29 PM
>To : twsocket@elists.org
>Cc :
>Subject : RE: Re: [twsocket] Early web server response
> I don't think it's current THttpCli's behav
Scrive "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
> Hello:
> Actually, I just found that this is defined in
> the RFC (probably to prevent DOS attacks):
[...]
> If this is not the current behaviour of the
> HttpCli component, then perhaps we can work in
> implementing this.
This night I
Scrive "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
> Hello:
[DOS attack]
Good point.
> I guess a way to overcome this in the client side
> would be to send a HEAD request prior to establish if
> the resource is available for consumption. If not,
> the server will respond with 401 and your cli
[EMAIL PROTECTED] wrote:
> Hello:
> Actually, I just found that this is defined in
> the RFC (probably to prevent DOS attacks):
>
> 8.2.2 Monitoring Connections for Error Status Messages
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.2
>
> "An HTTP/1.1 (or later) client se
Maurizio Lotauro wrote:
> Scrive "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
>
>> Hello:
>> Seems to be a server issue. Even if the server
>> requires authentication, the response should not be
>> sent until the entire request is received. This
>> behaviour is very strange indeed. Are you sure
Hello:
Actually, I just found that this is defined in
the RFC (probably to prevent DOS attacks):
8.2.2 Monitoring Connections for Error Status Messages
http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.2
"An HTTP/1.1 (or later) client sending a
message-body SHOULD monitor the
: twsocket@elists.org
>Cc :
>Subject : RE: Re: [twsocket] Early web server response
>
Yes. Using "Follow TCP Stream" of WireShark I see the
answer in the middle of
the request. Then I checked the single packet
(ordered by time) and it is
effectively so.
This happen by a cust
Scrive "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
> Hello:
> Seems to be a server issue. Even if the server
> requires authentication, the response should not be
> sent until the entire request is received. This
> behaviour is very strange indeed. Are you sure that
> the response is sent befo
completed)?
-dZ.
>--- Original Message ---
>From: Maurizio
Lotauro[mailto:[EMAIL PROTECTED]
>Sent: 9/17/2008 12:48:50 PM
>To : twsocket@elists.org
>Cc :
>Subject : RE: [twsocket] Early web server response
>
>Hello,
it seems that I have a
Hello,
it seems that I have a problem with the HttpCli component.
The client send an xml to the server using the POST method (synch). The server
require an authentication (basic). When the xml is greater than a certain size
(160k are enough) the server answer with a 400 (IIS/Tomcat: Bad request) o
65 matches
Mail list logo
