Hi,
I'm attempting to install ICS V7 using Codegear C++ Builder 2007. However, I
run into following error:
[DCC Error] OverByteIcsWSocketE.pas(87): F1026 File not found: '
DesignIntf.dcu'
A search for a solution gave me this:
> You need to add -LUDesigneIde to the dcc32 command line options.
U
Yes I realized that after sending the message. Then I sent the below
message, have you received it?:
Let me report more clearly: In the working/direct logs, we have
http://owa.bse-electronic.com/exchange
GET /exchange HTTP/1.1
Host: owa.bse-electronic.com
User-Agent: Mozilla/5.0 (Windows; U; W
Fastream Technologies wrote:
> In the direct connection logs, if you look at the first request that
> returns 401, its response has connection: close,
That's totally ok since at that time the auth-type is not yet negotiated.
However when the NTLM message type 1 is sent from the client to the serv
Let me report more clearly: In the working/direct logs, we have
http://owa.bse-electronic.com/exchange
GET /exchange HTTP/1.1
Host: owa.bse-electronic.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.12)
Gecko/20080201 Firefox/2.0.0.12
Accept: text/xml,application/xml,app
In the direct connection logs, if you look at the first request that returns
401, its response has connection: close, rather strange it worked that way.
Anyway, I think this link I posted is the closest I have as a clue...
On 3/15/08, Arno Garrels <[EMAIL PROTECTED]> wrote:
>
> > I asked the custo
> I asked the customer to enable
> keep-alive and hope that it will work without any modification.
Sure, NTLM auth requires Keep-Alive. However, in your log Keep-Alive
is already used correctly, so what will that change?
--
Arno Garrels
Fastream Technologies wrote:
> Hi Guys,
>
> I found this o
Hi Guys,
I found this on my research:
https://issues.apache.org/bugzilla/show_bug.cgi?id=39673
Seems that NTLM is crap since it assumes statefulness on a stateless
protocol (HTTP). Shame on M$. I asked the customer to enable keep-alive and
hope that it will work without any modification. FYI.
Be
Yes you are probably right--but the code is so simple and I checked the
header sent with socketspy and it is the same size (208 bytes after
"Authorization: NTLM ") in both direct and non-direct! As I said it is just
a tunnel. Is there a way to decrypt the header with some ready tool? I do
not want
Fastream Technologies wrote:
> When I trace the code, it seems that your web server side NTLM code
> is not called at all.
So, that is your implementation! If you do not call my code it
can hardly be the reason for the problem.
> It just tunnels the www-authenticate headers
> to/from the web ser
When I trace the code, it seems that your web server side NTLM code is not
called at all. It just tunnels the www-authenticate headers to/from the web
server. Can you suggest me some URLs so that I can read and understand what
the eath is wrong with NTLM handshake? You told me all is well in one of
10 matches
Mail list logo