On Fri, Apr 20, 2018 at 9:01 PM, Ruediger Pluem <rpl...@apache.org> wrote:
>
>
> On 04/20/2018 04:30 PM, yla...@apache.org wrote:
>> Author: ylavic
>> Date: Fri Apr 20 14:30:19 2018
>> New Revision: 1829659
>>
>> URL: http://svn.apache.org/viewvc?rev=1829659&view=rev
>> Log:
>> http: add ap_fgetline() and AP_GETLINE_NONBLOCK flag.
>>
>> It allows to read a line directly from an input filter, in blocking mode
>> or not. Since no request_rec is needed, a pool may be given.
>>
>> Existing ap_[r]getline() function are now based off ap_fgetline() by calling:
>>     ap_fgetline(s, n, read, r->proto_input_filters, flags, bb, r->pool);
>>
>> Will follow up with a new ap_get_mime_headers_*() flavor which can be used by
>> any filter that needs non-blocking and not necessarily has a request_rec 
>> (e.g.
>> ap_http_filter() to read proxied response trailers).
>>
>>
>> Modified:
>>     httpd/httpd/trunk/include/ap_mmn.h
>>     httpd/httpd/trunk/include/http_protocol.h
>>     httpd/httpd/trunk/server/protocol.c
>>
>
>> Modified: httpd/httpd/trunk/server/protocol.c
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/protocol.c?rev=1829659&r1=1829658&r2=1829659&view=diff
>> ==============================================================================
>> --- httpd/httpd/trunk/server/protocol.c (original)
>> +++ httpd/httpd/trunk/server/protocol.c Fri Apr 20 14:30:19 2018
>
>> @@ -517,10 +522,31 @@ cleanup:
>>      return rv;
>>  }
>>
>> +AP_DECLARE(apr_status_t) ap_fgetline(char **s, apr_size_t n,
>> +                                     apr_size_t *read, ap_filter_t *f,
>> +                                     int flags, apr_bucket_brigade *bb,
>> +                                     apr_pool_t *p)
>> +{
>> +    return ap_fgetline_impl(s, n, read, f, flags, bb, p);
>> +}
>> +
>> +/* Same as ap_fgetline(), working on r's pool and protocol input filters.
>> + * Pulls from r->proto_input_filters instead of r->input_filters for
>> + * stricter protocol adherence and better input filter behavior during
>> + * chunked trailer processing (for http).
>> + */
>> +AP_DECLARE(apr_status_t) ap_rgetline_core(char **s, apr_size_t n,
>> +                                          apr_size_t *read, request_rec *r,
>> +                                          int flags, apr_bucket_brigade *bb)
>> +{
>> +    return ap_fgetline_impl(s, n, read, r->proto_input_filters, flags,
>> +                            bb, r->pool);
>> +}
>> +
>>  #if APR_CHARSET_EBCDIC
>>  AP_DECLARE(apr_status_t) ap_rgetline(char **s, apr_size_t n,
>>                                       apr_size_t *read, request_rec *r,
>> -                                     int fold, apr_bucket_brigade *bb)
>> +                                     int flags, apr_bucket_brigade *bb)
>>  {
>>      /* on ASCII boxes, ap_rgetline is a macro which simply invokes
>>       * ap_rgetline_core with the same parms
>> @@ -532,8 +558,9 @@ AP_DECLARE(apr_status_t) ap_rgetline(cha
>>       */
>>      apr_status_t rv;
>>
>> -    rv = ap_rgetline_core(s, n, read, r, fold, bb);
>> -    if (rv == APR_SUCCESS || APR_STATUS_IS_ENOSPC(rv)) {
>> +    rv = ap_fgetline_impl(s, n, read, r->proto_input_filters, flags,
>> +                          bb, r->pool);
>> +    if (*read) {
>>          ap_xlate_proto_from_ascii(*s, *read);
>>      }
>>      return rv;
>> @@ -542,7 +569,6 @@ AP_DECLARE(apr_status_t) ap_rgetline(cha
>>
>>  AP_DECLARE(int) ap_getline(char *s, int n, request_rec *r, int flags)
>>  {
>> -    char *tmp_s = s;
>>      apr_status_t rv;
>>      apr_size_t len;
>>      apr_bucket_brigade *tmp_bb;
>> @@ -553,7 +579,8 @@ AP_DECLARE(int) ap_getline(char *s, int
>>      }
>>
>>      tmp_bb = apr_brigade_create(r->pool, r->connection->bucket_alloc);
>> -    rv = ap_rgetline(&tmp_s, n, &len, r, flags, tmp_bb);
>> +    rv = ap_fgetline_impl(&s, n, &len, r->proto_input_filters, flags,
>> +                          tmp_bb, r->pool);
>
> Hm, now ap_getline is no longer EBCDIC agnostic. Is this intended?

Nope, it was also missing EBCDIC translation for ap_fgetline() :/

Fixed in r1829789, thanks for the review!

Regards,
Yann.

Reply via email to