Using a variable on object level seems like a better approach than my
proposal of adding a SendType flag to dozen of functions :-)
The following lines may cause problems for file streams opened in
read/write mode, I guess, because it will truncate the file:
> @@ -2865,6 +2881,8 @@
> if FServ
Tobias Rapp wrote:
> Hi,
>
> I am currently debugging some problems in my application using the
> THttpServer/THttpConnection components regarding the support for HEAD
> requests. As far as I understand the specs no response body should be
> returned for HEAD but it seems that THttpConnection does
Hello Francois,
I've checked several times and I don't believe that I'm calling anything I
shouldn't but I could be wrong of course. Yes, I know ICS can handle fast
large scale communications.
Pardon the long text reply but below is the full code for the Socket's client
thread's Execute met
Hello Angus,
It's TCP. As far as I know, no visual components are updated since the sockets
have their own client threads. (Multithreaded = TRUE and a client thread is
started after the TWSocket instance is created. The first thing the client
thread does in its Execute() method is use the Thr
Hello Arno,
I'll try the wsoNoReceiveLoop option, thanks.
> make sure that you do not overflow the internal send buffer
I do that already. Whenever I go to transmit audio (call Send), I check the
buffered byte count waiting in the send queue and if it's non-zero I drop
frames (ignore the audi
I wrote:
> [...] As far as I understand the specs no response body should be
> returned for HEAD but it seems that THttpConnection does send response
> bodies in procedure ProcessPost() in case of 400/404/etc. answers.
^---^
I wanted to say ProcessHead() here.
Regard
Hi,
I am currently debugging some problems in my application using the
THttpServer/THttpConnection components regarding the support for HEAD
requests. As far as I understand the specs no response body should be
returned for HEAD but it seems that THttpConnection does send response
bodies in proced