httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike O'Leary" <>
Subject Re: ap_rwrite
Date Thu, 29 May 2008 20:23:58 GMT

Thanks for taking the time to respond.  My question was more about how the
Apache socket API works.  I'm actually not experiencing any problems.  I was
just wondering if the ap_rwrite call could return some value less than the
number of bytes requested to be written.  I wanted to know if I need to put
a loop around all of my ap_rwrite calls to verify that all the data is
sent.  I'll probably just add the loop to make sure, but I'm not sure if
I'll need it.


On Tue, May 27, 2008 at 1:21 PM, Samuel Gomez <>

> Hello Mike.
> Two notes on your topic.
> 1.- In httpd.h there is a constant called MAX_STRING_LEN . Maybe is playing
> some role here. Did you notice if buffer printing gets cut just when exceeds
> the number of bytes defined in MAX_STRING_LEN ?
> 2.- For string printing, I use ap_rputs()
> Not based in any special reason. Simply it is the funcion I saw on some
> tutorials and I use it. Test it. I always use it for printing short strings,
> but maybe is useful also in your case.
> Samuel
> Mike O'Leary wrote:
>> Hello,
>> I am writing an Apache module using Apache 2.2.3 and, from what I
>> understand, the sockets are non-blocking.  My questions is about ap_rwrite
>> having the signature below:
>> AP_DECLARE(int) ap_rwrite(const void *buf, int nbyte, request_rec *r);
>> Is it possible that ap_rwrite returns some value less than nbyte, but not
>> -1?  This would mean that I would need to loop, passing some byte offset
>> into buf and reducing nbyte until all of the content was sent.  If it is
>> not
>> possible for ap_rwrite to return some value less than nbyte other than -1,
>> is there some internal mechanism that is looking to enforce a specific
>> transfer rate and will time out and return -1 from ap_rwrite if this rate
>> is
>> not achieved?  If this is not the case, then aren't the sockets blocking?
>> Thanks in advance!
>> -Mike

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message