Re: HTTP_MISDIRECTED_REQUEST

[Roy T. Fielding]

> On Aug 26, 2015, at 3:15 PM, William A Rowe Jr  > wrote:
> 
> Should this exception have a protocol version guard for HTTP/2.0 requests, 
> and leave the response as HTTP_BAD_REQUEST for HTTP/1.1 and earlier?
> 
> @@ -203,6 +204,9 @@
>  ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server, 
> APLOGNO(02032)
>  "Hostname %s provided via SNI and hostname %s 
> provided"
>  " via HTTP are different", servername, host);
> +if (r->connection->keepalives > 0) {
> +return HTTP_MISDIRECTED_REQUEST;
> +}
>  return HTTP_BAD_REQUEST;
>  }
>  }

IIRC, it is applicable to HTTP/1.1 as well. Think misdirected requests 
containing
an absolute request URI that points to some other server.  I don't think the 
conditional
is needed at all -- just return HTTP_MISDIRECTED_REQUEST.

Hmm, I wonder how this impacts Google's desire to allow multiple hosts to reuse
the same SPDY connection ... was that dropped for h2?

Roy

Re: svn commit: r1698133 - in /httpd/httpd/trunk: include/httpd.h modules/http2/h2_switch.c server/protocol.c server/util.c

[William A Rowe Jr]

On Aug 27, 2015 7:14 AM,  wrote:
>
> Author: icing
> Date: Thu Aug 27 12:13:59 2015
> New Revision: 1698133
>
> URL: http://svn.apache.org/r1698133
> Log:
> giving ap_array_index a start parameter, adding ap_array_contains
>

>   */
> -AP_DECLARE(int) ap_array_index(const apr_array_header_t *array, const
char *s);
> +AP_DECLARE(int) ap_array_index(const apr_array_header_t *array,
> +   const char *s,
> +   apr_size_t start);

You want the type of rv of _index to correspond to the start input to rv,
no?  E.g.

int n = -1, count = 0;
while ((n = ap_array_index(arr, findtag, n + 1)) >= 0)
++count;

sizeof(int) does not have to equal sizeof(apr_size_t).  But for indexes I
believe it's fine.  The alternative is apr_ssize_t for both start arg and
rv.

Re: svn commit: r1698117 - /httpd/httpd/branches/2.4.x/STATUS

[Yann Ylavic]

On Thu, Aug 27, 2015 at 2:21 PM, Stefan Eissing
 wrote:
>
> The first half about http_protocol.h does. From this and all other changes, 
> the directory modules/http2 needs to be ignored. Is that a problem?

No problem, partial merges are fine.
My bad, I thought r1698116's changes on http_protocol.h were not in
core-protocols.patch, but that's the case (maybe increasing some
number in the patch name would help when it is updated).

Re: Getting all supported protocols

[Edward Lu]

Thanks Stefan.

On Thu, Aug 27, 2015 at 7:19 AM, Stefan Eissing <
stefan.eiss...@greenbytes.de> wrote:

> Implemented in r1698116. Will add to core-protocols patch now.
>
> Reviewers: This is a clarification of the protocols hook API without any
> code changes in core.
>
> > Am 26.08.2015 um 18:39 schrieb Edward Lu :
> >
> > Yes, that's right - the toolkit does itself decide which protocol is
> used. However, it decides based on the order of the protocols we pass to
> it; that is, it will find the first protocol in the list supported by the
> client and negotiate it. We will order the list ourselves according to
> Protocols and ProtocolsHonorOrder.
> >
> > The general structure of this toolkit's API is quite different OpenSSL's
> - it's not callback-based, all we do is pass it a bunch of parameters and
> then tell it to go ahead with the handshake. I think that may have
> influenced this API more than NPN.
> >
> >
> > On Wed, Aug 26, 2015 at 11:20 AM, Stefan Eissing <
> stefan.eiss...@greenbytes.de> wrote:
> > Hmm, this was the kind of behaviour of NPN, maybe that influenced the
> API of that toolkit?
> >
> > I imagine that the toolkit will decide itself then what protocol is
> negotiated. That would mean that the directive ProtocolsHonorOrder has no
> longer an effect. Am I right?
> >
> > I do not think that is what we want.
> >
> > //Stefan
> >
> > > Am 26.08.2015 um 17:02 schrieb Edward Lu :
> > >
> > > I was experimenting with the new support for declaring protocols for
> e.g. ALPN, but with an SSL toolkit other than openssl. This one wants us to
> pass the entire list of all the protocols the server supports in advance;
> later, we can request the one protocol that the toolkit negotiated.
> > >
> > > It looks like the protocol_propose hook allows us to only grab a
> subset of the protocols - i.e. it expects us to have the protocol list that
> the client sends us. I've attached a patch which modifies the
> protocol_propose hook's interface (documentation), allowing us to get all
> of the protocols supported by the server. I also modified h2's
> implementation of the hook to reflect the interface change.
> > >
> > > Let me know if anyone sees a problem.
> > >
> > > 
> >
> > bytes GmbH
> > Hafenweg 16, 48155 Münster, Germany
> > Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
> >
> >
> >
> >
>
> bytes GmbH
> Hafenweg 16, 48155 Münster, Germany
> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>
>
>
>

Re: svn commit: r1698117 - /httpd/httpd/branches/2.4.x/STATUS

[Stefan Eissing]

> Am 27.08.2015 um 13:34 schrieb Yann Ylavic :
> 
> On Thu, Aug 27, 2015 at 1:25 PM,   wrote:
>> Author: icing
>> Date: Thu Aug 27 11:25:09 2015
>> New Revision: 1698117
>> 
>> URL: http://svn.apache.org/r1698117
>> Log:
>> adding r1698116 to core-protocols.patch to clarify new api
>> 
>> Modified:
>>httpd/httpd/branches/2.4.x/STATUS
>> 
>> Modified: httpd/httpd/branches/2.4.x/STATUS
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1698117&r1=1698116&r2=1698117&view=diff
>> ==
>> --- httpd/httpd/branches/2.4.x/STATUS (original)
>> +++ httpd/httpd/branches/2.4.x/STATUS Thu Aug 27 11:25:09 2015
>> @@ -312,6 +312,7 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>>   http://svn.apache.org/r1610674 (partial)
>>   http://svn.apache.org/r1685069
>>   http://svn.apache.org/r1693918
>> +  http://svn.apache.org/r1698116
> 
> Looks like it does not belong to this patchset (and the patch below)

The first half about http_protocol.h does. From this and all other changes, the 
directory modules/http2 needs to be ignored. Is that a problem?

bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: modules\http2 - structure initializing.

[NormW]

Yann, Sorry for the delay,
In simple terms, no; it is obvious the compiler (other people use other 
names) just sees that as a single item list, and complains about the 
syntax, regardless of how many items are in the list.


To be honest up to this point the compiler has been able to build 
everything (including all of httpd-trunk), and I proposed the small 
variations suggested in the diff on the grounds I (and evidently a few 
others) thought the suggested format was clearer.


However, it is not MY intention to limit in any way the functionality of 
tomorrows software solely so NetWare can make some show of trying to 
keep up. I've no idea how much more coding is needed for your project, 
and it may be that the next change or the 100th from now will be beyond 
the capabilities of what tools I have to use, and the race will be over 
for both the horse and the rider. Code as you see fit and if it 
eventuates that NetWare can't keep up, there's a lot of others who will.

Regards,
Norm

On 27/08/2015 8:29 PM, Yann Ylavic wrote:

Hi,

On Wed, Aug 26, 2015 at 12:53 AM, NormW  wrote:

Herewith an svn diff that implements line-by-line initialization of three
structures (no idea if there's a technical term for it) in place of the list
method now used, e.g struct x = { , , , }.

I acknowledge upfront that 'my' somewhat dated compiler cannot handle the
list method, whereas the method portrayed in the diff is totally acceptable
to it.


Does it accept x = {0} still?

Regards,
Yann.

Re: svn commit: r1698117 - /httpd/httpd/branches/2.4.x/STATUS

[Yann Ylavic]

On Thu, Aug 27, 2015 at 1:25 PM,   wrote:
> Author: icing
> Date: Thu Aug 27 11:25:09 2015
> New Revision: 1698117
>
> URL: http://svn.apache.org/r1698117
> Log:
> adding r1698116 to core-protocols.patch to clarify new api
>
> Modified:
> httpd/httpd/branches/2.4.x/STATUS
>
> Modified: httpd/httpd/branches/2.4.x/STATUS
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1698117&r1=1698116&r2=1698117&view=diff
> ==
> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Thu Aug 27 11:25:09 2015
> @@ -312,6 +312,7 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>http://svn.apache.org/r1610674 (partial)
>http://svn.apache.org/r1685069
>http://svn.apache.org/r1693918
> +  http://svn.apache.org/r1698116

Looks like it does not belong to this patchset (and the patch below).

>  2.4.x patch: 
> https://raw.githubusercontent.com/icing/mod_h2/master/sandbox/httpd/patches/core-protocols.patch
>  +1: icing,
>
>
>

Re: Getting all supported protocols

[Stefan Eissing]

Implemented in r1698116. Will add to core-protocols patch now.

Reviewers: This is a clarification of the protocols hook API without any code 
changes in core.

> Am 26.08.2015 um 18:39 schrieb Edward Lu :
> 
> Yes, that's right - the toolkit does itself decide which protocol is used. 
> However, it decides based on the order of the protocols we pass to it; that 
> is, it will find the first protocol in the list supported by the client and 
> negotiate it. We will order the list ourselves according to Protocols and 
> ProtocolsHonorOrder.
> 
> The general structure of this toolkit's API is quite different OpenSSL's - 
> it's not callback-based, all we do is pass it a bunch of parameters and then 
> tell it to go ahead with the handshake. I think that may have influenced this 
> API more than NPN.
> 
> 
> On Wed, Aug 26, 2015 at 11:20 AM, Stefan Eissing 
>  wrote:
> Hmm, this was the kind of behaviour of NPN, maybe that influenced the API of 
> that toolkit?
> 
> I imagine that the toolkit will decide itself then what protocol is 
> negotiated. That would mean that the directive ProtocolsHonorOrder has no 
> longer an effect. Am I right?
> 
> I do not think that is what we want.
> 
> //Stefan
> 
> > Am 26.08.2015 um 17:02 schrieb Edward Lu :
> >
> > I was experimenting with the new support for declaring protocols for e.g. 
> > ALPN, but with an SSL toolkit other than openssl. This one wants us to pass 
> > the entire list of all the protocols the server supports in advance; later, 
> > we can request the one protocol that the toolkit negotiated.
> >
> > It looks like the protocol_propose hook allows us to only grab a subset of 
> > the protocols - i.e. it expects us to have the protocol list that the 
> > client sends us. I've attached a patch which modifies the protocol_propose 
> > hook's interface (documentation), allowing us to get all of the protocols 
> > supported by the server. I also modified h2's implementation of the hook to 
> > reflect the interface change.
> >
> > Let me know if anyone sees a problem.
> >
> > 
> 
> bytes GmbH
> Hafenweg 16, 48155 Münster, Germany
> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
> 
> 
> 
> 

bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: modules\http2 - structure initializing.

[Yann Ylavic]

Hi,

On Wed, Aug 26, 2015 at 12:53 AM, NormW  wrote:
> Herewith an svn diff that implements line-by-line initialization of three
> structures (no idea if there's a technical term for it) in place of the list
> method now used, e.g struct x = { , , , }.
>
> I acknowledge upfront that 'my' somewhat dated compiler cannot handle the
> list method, whereas the method portrayed in the diff is totally acceptable
> to it.

Does it accept x = {0} still?

Regards,
Yann.

Re: modules\http2 - structure initializing.

[Stefan Eissing]

Submitted in r1698107.

> Am 26.08.2015 um 23:41 schrieb NormW :
> 
> Whinnnie!
> (eq Equine 'Thanks')
> On 27/08/2015 7:31 AM, Stefan Eissing wrote:
>> I will apply the proposed change tomorrow. keep the old horse happy.
>> 
>> //stefan
>> 
>>> Am 26.08.2015 um 23:18 schrieb NormW :
>>> 
>>> G/Morning I think,
>>> As Bill correctly guesses in a following mail, 'my' OS is NetWare and it's 
>>> the standard compiler GK has been using for years to build Apache releases.
>>> 
>>> And that (Metrowerks CW) (AFAIK) is a C89 legend.
>>> 
>>> As I noted in my mail, I would hardly expect to hold back tomorrows http/2 
>>> protocol for so dated a horse as NetWare, and if you introduced coding or 
>>> functions that NetWare's compiler doesn't support then it's 'game-over' for 
>>> the old war horse as far as http2 is concerned. For the moment however I 
>>> merely suggest an opinion that initializing structures via a list of 
>>> individual assignments is a better form to read the code than what is used 
>>> at present, and a small, almost irrelevant side effect of which is that, 
>>> for now at least, my compiler can keep building http2 for NetWare, with no 
>>> functional change to the code.
>>> Regards,
>>> Norm
>>> 
 On 27/08/2015 1:26 AM, Stefan Eissing wrote:
 Hi Norm,
 
 I think these type of assignments are part of the C90 standard. I am not 
 sure we want to support a compiler that cannot cope with that, but I may 
 be to green to know that. What platform is this on exactly?
 
 //Stefan
 
> Am 26.08.2015 um 00:53 schrieb NormW :
> 
> G/Morning,
> Herewith an svn diff that implements line-by-line initialization of three 
> structures (no idea if there's a technical term for it) in place of the 
> list method now used, e.g struct x = { , , , }.
> 
> I acknowledge upfront that 'my' somewhat dated compiler cannot handle the 
> list method, whereas the method portrayed in the diff is totally 
> acceptable to it.
> 
> However, I find the 'list' method less easier to 'read' as the struct 
> elements are not 'visible', and one has to locate the struct definition 
> itself to see what is being set to what. The method as illustrated by the 
> patch is clearer (to my mind) and not affected by the order of the 
> elements within the primary structure.
> 
> Lastly I noticed at least one case recently where my diff 'simplified' 
> because a struct was changed to the _suggested_ method, with the primary 
> struct being created by a memset(); perhaps that's a similar change 
> needed in these cases also?
> 
> Regards,
> Norm
> 
> 
> 
> 
 
 bytes GmbH
 Hafenweg 16, 48155 Münster, Germany
 Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>>> 
> 

bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: HTTP Server Project hackathon/BoF in Budapest?

[Yann Ylavic]

On Wed, Aug 26, 2015 at 7:03 PM, Yann Ylavic  wrote:
> On Wed, Aug 26, 2015 at 5:29 PM, William A Rowe Jr  
> wrote:
>> First question, will many of us be present and available during the day
>> Wednesday ahead of the ApacheCon Core content for a hackathon and BoF, or
>> would it be better for these things to happen on Thursday during/in the
>> evening of Core?
>
> I'll be there on Wednesday, and Thurday too but not the evening.

Wrong dates! I'll be there on Thursday until Friday (evening).
So I'm available both days for the hackathon/BoF.

>
> Regards,
> Yann.

Re: APACHE_CHECK_NGHTTP2

[Stefan Eissing]

Ah, got it now. Patch incoming.

> Am 27.08.2015 um 11:31 schrieb Stefan Eissing :
> 
> Just tried it, cannot get it to work. Some volunteer for this?
> 
>> Am 27.08.2015 um 00:06 schrieb William A Rowe Jr :
>> 
>> Just a quick observation before backport of mod_h2 is proposed...
>> 
>> Moving the macro APACHE_CHECK_NGHTTP2 out of acinclude.m4 into 
>> modules/http2/config.m4 lets me build (after a ./buildconf) after simply 
>> checking out modules/http2/ from trunk.
>> 
>> In terms of ease-of-integration, do we see other modules we expect to 
>> utilize libnghttp2, e.g. mod_proxy_http?  If so, this probably isn't the 
>> right solution, but it makes an interesting and quick stop-gap.
>> 
>> 
> 
> bytes GmbH
> Hafenweg 16, 48155 Münster, Germany
> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
> 
> 
> 

bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: APACHE_CHECK_NGHTTP2

[Stefan Eissing]

Just tried it, cannot get it to work. Some volunteer for this?

> Am 27.08.2015 um 00:06 schrieb William A Rowe Jr :
> 
> Just a quick observation before backport of mod_h2 is proposed...
> 
> Moving the macro APACHE_CHECK_NGHTTP2 out of acinclude.m4 into 
> modules/http2/config.m4 lets me build (after a ./buildconf) after simply 
> checking out modules/http2/ from trunk.
> 
> In terms of ease-of-integration, do we see other modules we expect to utilize 
> libnghttp2, e.g. mod_proxy_http?  If so, this probably isn't the right 
> solution, but it makes an interesting and quick stop-gap.
> 
> 

bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: HTTP Server Project hackathon/BoF in Budapest?

[Stefan Eissing]

I will arrive on Wednesday evening.

> Am 27.08.2015 um 10:46 schrieb jean-frederic clere :
> 
> On 08/26/2015 05:29 PM, William A Rowe Jr wrote:
>> First question, will many of us be present and available during the day
>> Wednesday ahead of the ApacheCon Core content for a hackathon and BoF,
>> or would it be better for these things to happen on Thursday during/in
>> the evening of Core?
> 
> I will be there and might have cycles :D
> 
> Cheers
> 
> Jean-Frederic

bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: proposed backport, mod_h2 github release

[Stefan Eissing]

Latest is 1.0.2d, but the c will also do. 1.0.1 does not seem to have it.

> Am 27.08.2015 um 10:48 schrieb jean-frederic clere :
> 
> Hi.
> 
> Just to clarify the openssl minimal version to use to have h2 working is 
> 1.0.2c correct? Or did I miss something?
> 
> Cheers
> 
> Jean-Frederic

bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: proposed backport, mod_h2 github release

[Stefan Eissing]

> Am 26.08.2015 um 23:21 schrieb Gregg Smith :
> 
> On 8/26/2015 6:44 AM, Stefan Eissing wrote:
>> I just submitted my first backport STATUS update. Hope I did everything ok, 
>> otherwise please let me know.
>> 
>> For backporting mod_h2 to 2.4.x, I decided to make it in two parts: one is 
>> the patch to core/mod_ssl that introduces Protocols. That is now in STATUS.
> 
> Needs r1693918, other than that all seems ok so far :)

Thanks, nice catch. This C89 thing is killing me...

Updated STATUS and patch file on github.

bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: proposed backport, mod_h2 github release

[jean-frederic clere]

Hi.

Just to clarify the openssl minimal version to use to have h2 working is 
1.0.2c correct? Or did I miss something?


Cheers

Jean-Frederic

Re: HTTP Server Project hackathon/BoF in Budapest?

[jean-frederic clere]

On 08/26/2015 05:29 PM, William A Rowe Jr wrote:

First question, will many of us be present and available during the day
Wednesday ahead of the ApacheCon Core content for a hackathon and BoF,
or would it be better for these things to happen on Thursday during/in
the evening of Core?


I will be there and might have cycles :D

Cheers

Jean-Frederic

Re: modules\http2 - H2Engine directive?

[Stefan Eissing]

One more thing.

If you want to demo with chrome, you need to enforce server order of protocols, 
since chrome currently specifies ALPN protocols in the wrong order. Chrome Bug 
is open and assigned.

So, for now you might want to do:

Protocols h2 http/1.1
ProtocolsHonorOrder on

Firefox, curl, python works right out of the box.

//Stefan

> Am 27.08.2015 um 10:22 schrieb jean-frederic clere :
> 
> On 08/24/2015 10:06 AM, Stefan Eissing wrote:
>> Ni Norm,
>> 
>> yes, I removed it last week
> 
> If I want on VirtualHost with h2 support and another one without how should I 
> do that? (that is for demo purpose)
> 
> Cheers
> 
> Jean-Frederic

bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: modules\http2 - H2Engine directive?

[NormW]

Good evening,
Just a 'guess' Use a Protocols directive in one vhost that doesn't 
have h2 and dirivitives

Norm

On 27/08/2015 6:22 PM, jean-frederic clere wrote:

On 08/24/2015 10:06 AM, Stefan Eissing wrote:

Ni Norm,

yes, I removed it last week


If I want on VirtualHost with h2 support and another one without how
should I do that? (that is for demo purpose)

Cheers

Jean-Frederic

Re: modules\http2 - H2Engine directive?

[Stefan Eissing]

> Am 27.08.2015 um 10:22 schrieb jean-frederic clere :
> 
> On 08/24/2015 10:06 AM, Stefan Eissing wrote:
>> Ni Norm,
>> 
>> yes, I removed it last week
> 
> If I want on VirtualHost with h2 support and another one without how should I 
> do that? (that is for demo purpose)
> 
> Cheers
> 
> Jean-Frederic

The default for "Protocols" is: everything. My thinking: when a Server loads 
mod_h2, it wants it enabled. 

1st way (just do it): 
--

  ServerName with.example.org



  ServerName without.example.org
  Protocols http/1.1


1st way (explicit h2, excluding any other in future enabled protocol): 
--
Protocols h2 http/1.1

  ServerName with.example.org



  ServerName without.example.org
  Protocols http/1.1


2nd way (the careful way): 
--
Protocols http/1.1

  ServerName with.example.org
  Protocols h2 http/1.1



  ServerName without.example.org



bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: modules\http2 - H2Engine directive?

[jean-frederic clere]

On 08/24/2015 10:06 AM, Stefan Eissing wrote:

Ni Norm,

yes, I removed it last week


If I want on VirtualHost with h2 support and another one without how 
should I do that? (that is for demo purpose)


Cheers

Jean-Frederic

RE: APACHE_CHECK_NGHTTP2

[Plüm , Rüdiger , Vodafone Group]

> -Original Message-
> From: Jim Jagielski [mailto:j...@jagunet.com]
> Sent: Donnerstag, 27. August 2015 01:13
> To: dev@httpd.apache.org
> Subject: Re: APACHE_CHECK_NGHTTP2
> 
> 
> > On Aug 26, 2015, at 6:19 PM, Eric Covener  wrote:
> >
> > On Wed, Aug 26, 2015 at 6:06 PM, William A Rowe Jr 
> wrote:
> >> In terms of ease-of-integration, do we see other modules we expect to
> >> utilize libnghttp2, e.g. mod_proxy_http?  If so, this probably isn't
> the
> >> right solution, but it makes an interesting and quick stop-gap.
> >
> > I would prefer the mod_h2-only arrangement. I think mod_proxy_http is
> > extremely far away.
> 
> Agreed.

+1

Regards

Rüdiger