Re: mod_proxy ping and r->expecting_100
On Thu, Oct 10, 2013 at 1:10 AM, Yann Ylavic wrote: > RFC2616 10.1 (above above) states that "Proxies MUST forward 1xx responses > [unless client's connection closed]". > But with the current implementation, the client as nothing to "Continue" > at that point, its whole body is already gone. > Since taking care of not writing on a closed connection looks weird (for a > RFC), couldn't "closed" mean EOS here, and mod_proxy_http should not > forward any "100 Continue" response whatever ENV:proxy-interim-response is? > Or is it a "Connection: close"d (and alike: no-CL + no-TE) ? In that case it would have to be handled wherever r->expecting_100 is... Regards. >
Re: svn commit: r1524770 - in /httpd/httpd/trunk: CHANGES modules/http/http_filters.c server/protocol.c
Could this be backported please ?
The corresponding 2.4.x patch is attached...
Regards,
Yann.
On Thu, Sep 19, 2013 at 5:30 PM, wrote:
> Author: jim
> Date: Thu Sep 19 15:30:10 2013
> New Revision: 1524770
>
> URL: http://svn.apache.org/r1524770
> Log:
> draft-ietf-httpbis-p1-messaging-23 fixes regarding interactions
> between TE and content-length in the same req/resp.
>
> Modified:
> httpd/httpd/trunk/CHANGES
> httpd/httpd/trunk/modules/http/http_filters.c
> httpd/httpd/trunk/server/protocol.c
>
> Modified: httpd/httpd/trunk/CHANGES
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1524770&r1=1524769&r2=1524770&view=diff
>
> ==
> --- httpd/httpd/trunk/CHANGES [utf-8] (original)
> +++ httpd/httpd/trunk/CHANGES [utf-8] Thu Sep 19 15:30:10 2013
> @@ -1,6 +1,9 @@
> -*- coding:
> utf-8 -*-
> Changes with Apache 2.5.0
>
> + *) core: draft-ietf-httpbis-p1-messaging-23 corrections regarding
> + TE/CL conflicts. [Yann Ylavic , Jim Jagielski]
> +
>*) mod_proxy_fcgi: Use apr_socket_timeout_get instead of hard-coded
> 30 seconds timeout. [Jan Kaluza]
>
>
> Modified: httpd/httpd/trunk/modules/http/http_filters.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_filters.c?rev=1524770&r1=1524769&r2=1524770&view=diff
>
> ==
> --- httpd/httpd/trunk/modules/http/http_filters.c (original)
> +++ httpd/httpd/trunk/modules/http/http_filters.c Thu Sep 19 15:30:10 2013
> @@ -224,25 +224,32 @@ apr_status_t ap_http_filter(ap_filter_t
> lenp = apr_table_get(f->r->headers_in, "Content-Length");
>
> if (tenc) {
> -if (!strcasecmp(tenc, "chunked")) {
> +if (strcasecmp(tenc, "chunked") == 0 /* fast path */
> +|| ap_find_last_token(f->r->pool, tenc, "chunked")) {
> ctx->state = BODY_CHUNK;
> }
> -/* test lenp, because it gives another case we can handle */
> -else if (!lenp) {
> -/* Something that isn't in HTTP, unless some future
> - * edition defines new transfer encodings, is unsupported.
> +else if (f->r->proxyreq == PROXYREQ_RESPONSE) {
> +/*
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-23
> + * Section 3.3.3.3: "If a Transfer-Encoding header field
> is
> + * present in a response and the chunked transfer coding
> is not
> + * the final encoding, the message body length is
> determined by
> + * reading the connection until it is closed by the
> server."
> */
> ap_log_rerror(
> -APLOG_MARK, APLOG_INFO, 0, f->r, APLOGNO(01585)
> "Unknown Transfer-Encoding: %s", tenc);
> -return APR_ENOTIMPL;
> +APLOG_MARK, APLOG_INFO, 0, f->r, APLOGNO(01586)
> "Unknown Transfer-Encoding: %s; using read-until-close", tenc);
> +tenc = NULL;
> }
> else {
> +/* Something that isn't a HTTP request, unless some future
> + * edition defines new transfer encodings, is unsupported.
> + */
> ap_log_rerror(
> -APLOG_MARK, APLOG_WARNING, 0, f->r,
> APLOGNO(01586) "Unknown Transfer-Encoding: %s; using Content-Length", tenc);
> -tenc = NULL;
> +APLOG_MARK, APLOG_INFO, 0, f->r, APLOGNO(01585)
> "Unknown Transfer-Encoding: %s", tenc);
> +return APR_EGENERAL;
> }
> +lenp = NULL;
> }
> -if (lenp && !tenc) {
> +if (lenp) {
> char *endstr;
>
> ctx->state = BODY_LENGTH;
>
> Modified: httpd/httpd/trunk/server/protocol.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/protocol.c?rev=1524770&r1=1524769&r2=1524770&view=diff
>
> ==
> --- httpd/httpd/trunk/server/protocol.c (original)
> +++ httpd/httpd/trunk/server/protocol.c Thu Sep 19 15:30:10 2013
> @@ -1091,6 +1091,8 @@ request_rec *ap_read_request(conn_rec *c
> }
>
> if (!r->assbackwards) {
> +const char *tenc;
> +
> ap_get_mime_headers_core(r, tmp_bb);
> if (r->status != HTTP_OK) {
> ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r, APLOGNO(00567)
> @@ -1102,13 +1104,33 @@ request_rec *ap_read_request(conn_rec *c
> goto traceout;
> }
>
> -if (apr_table_get(r->headers_in, "Transfer-Encoding")
> -&& apr_table_get(r->headers_in, "Content-Length")) {
> -/*
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-23#page-31
> - * "If a m
Re: [PATCH 55593] Add "SSLServerInfoFile" directive
On Wed, Oct 9, 2013 at 6:52 AM, Dr Stephen Henson wrote: > > Technically the "current certificate" concept doesn't need exposing at all. > You > just have to make sure you set all the relevant parameters *after* you set the > certificate they apply to and *before* you set another one. Hi Stephen, Thanks a lot for your continued help. I'm trying to figure out how to do that: In ssl_engine_config.c, when a ServerInfoFile is encountered in the config file (whether directive or SSL_CONF), the code could look at sc->server->pks->cert_files to figure out the most recent "SSLCertificateFile", and its index. But by ssl_engine_init.c, the certs have been read, parsed, and translated into a table indexed by algorithm type, and accessed via ssl_asn1_table_get(...). How would you expect the code to track the Cert -> ServerInfo relationship between these points? Trevor
Re: [PATCH 55593] Add "SSLServerInfoFile" directive
On 10/10/2013 23:18, Trevor Perrin wrote: > > How would you expect the code to track the Cert -> ServerInfo > relationship between these points? > Disclaimer: it's been a while since I looked at that code and someone else might have a better idea. It didn't quite work in the way I recalled. It may be a bit messy to handle, to say the least. AFAICS the certificate and key files both go through the function ssl_cmd_check_aidx_max and store the filenames with an associated index. At that point you could save the last index used and store any associated ServerInfo with the same index. I *think* you then have to delve into ssl_pphrase_Handle() [note the comment on the way in] and somehow link the ServerInfo index with something you can use to recognise it later. The algorithm type 'at' might be usable or perhaps turn the algorithm type into one of the SSL_AIDX_ values? After that you look for an appropriate ServerInfo value when SSL_use_certificate or SSL_use_PrivateKey is called (you'll be able to use the associated SSL_AIDX_ value) and set the ServerInfo. There *should* be an easier way to do it than this but I can't immediately see what it is. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [PATCH 55593] Add "SSLServerInfoFile" directive
On 09.10.2013 15:52, Dr Stephen Henson wrote: > It's tempting to just add a directive but after some thought I think expanding > Apache SSL_CONF handling is the way to go. This would add some future proofing > so we don't have to go through this all again in future. Yes, please. Let's not perpetuate the pattern of adding another directive to mod_ssl whenever a new OpenSSL feature needs to be exposed. As an interim step, and sort of a proof of concept, it might be worthwile to see if adding equivalents of SSLCertificateFile and SSLCertificateKeyFile to SSLOpenSSLConfCmd (in ssl/ssl_conf.c, at the OpenSSL end) would allow support for per-cert options. The concept of collecting the options in ssl_cmd_SSLOpenSSLConfCmd and replying them at the appropriate place in ssl_engine_init.c would remain, and you would use something like OpenSSLConfCmd KeyFile foo.key OpenSSLConfCmd CertificateFile foo.crt OpenSSLConfCmd ServerInfoFile foo.pem OpenSSLConfCmd KeyFile bar.key OpenSSLConfCmd CertificateFile bar.crt OpenSSLConfCmd ServerInfoFile bar.pem to configure multiple cert and "current-cert" settings in turn (and not worry about the case of encrypted private keys, for the time being). "KeyFile" would result in calling SSL_CTX_use_PrivateKey_file(), and "CertificateFile" in SSL_CTX_use_certificate_chain_file(). ssl_engine_init.c:ssl_init_server_ctx() is most likely the appropriate place for inserting this (i.e., it's perhaps best to move the current SSL_CONF_CMD block from the end of ssl_init_ctx_protocol() to somewhere in ssl_init_server_ctx(), maybe some tweaks are needed for ssl_init_server_certs(), too). What I would try to avoid right now is fiddling with the tPublicCert, tVHostKey and tPrivateKey hashes (and the ssl_asn1_table_* friends). Kaspar
