Philip Martin writes:
> While debugging a problem reported on users I accidentally sent an extra
> byte to the client: I sent Content-Length of N and then sent N+1 bytes.
> The first N bytes made a valid response, so serf was happy at that
> stage. When processing the next request the extra byte
Looking at serf_context_run() I see
while (num--) {
serf_connection_t *conn = desc->client_data;
status = serf_event_trigger(ctx, conn, desc);
if (status) {
return status;
}
desc++;
}
When I look at conn[0] gdb it is junk. Looking at
Stefan Fuhrmann wrote:
[...]
> Yes, you are right. I'll fix this.
[...]
> I'll add test code for these as well.
Thanks.
After that you might want to eliminate the recursion, trivially, in both
functions:
if //it overlaps
{
bytes = apr_pmemdup(str->pool, bytes, count);
// don't
For Your Interest,
I am having some success with testing for equality between the outputs of
svnrdump and svnadmin dump.
The attached patch makes the test suite run both 'svnadmin dump' and 'svnrdump
dump' on the sandbox repository (if created) after each test, and compare the
results. This i
On Fri, Jan 9, 2015 at 6:52 PM, Julian Foad
wrote:
> I just spotted this.
>
> svn_stringbuf_insert() contains this:
>
> temp = apr_pstrndup(str->pool, bytes, count);
>
>
> That's wrong for an arbitrary array of bytes, because it will stop copying
> at the first null byte.
>
> Using apr_pmemdup(
I just spotted this.
svn_stringbuf_insert() contains this:
temp = apr_pstrndup(str->pool, bytes, count);
That's wrong for an arbitrary array of bytes, because it will stop copying at
the first null byte.
Using apr_pmemdup() should fix it.
Same in svn_stringbuf_replace().
Inadequate test c
Philip Martin writes:
> Index: buckets/response_buckets.c
> ===
> --- buckets/response_buckets.c(revision 2445)
> +++ buckets/response_buckets.c(working copy)
> @@ -129,7 +129,10 @@ static apr_status_t parse_status_li
writes:
>> I noticed that your proxy is changing the status line by dropping the
>> reason-phrase:
>>
>>HTTP/1.1 207 Multi-Status
>>
>> to
>>
>>HTTP/1.1 207
> Good news! I could create a new implementation of the JDK HttpServer
> which fixes the 207 Status line problem, and I can't r
8 matches
Mail list logo
