The requested URL /as was not found on this server.
Hi, I am writing a simple apache module following the docs in https://httpd.apache.org/docs/2.4/developer/modguide.html#snippets Here's the module code: http://pastebin.com/T1TMfLgC Here's my httpd.conf file: http://pastebin.com/aZBWyNve When I access any URL like localhost/asd I get the following error Not Found The requested URL /asd was not found on this server. Can you please help me fix this ?
Re: Using UPN from subjectAltName with SSLUserName
On 06/29/2015 03:14 PM, Jan Pazdziora wrote: On Mon, Jun 29, 2015 at 01:47:45PM +0200, Jan Pazdziora wrote: On Sun, Jun 28, 2015 at 05:11:57PM +0200, Kaspar Brand wrote: On 22.06.2015 10:37, Jan Pazdziora wrote: Please find a new patch attached which I hope covers all the parts you've outlined, for SSL_CLIENT_SAN_OTHER_msUPN_*. Thanks. Your implementation assumes that only a single otherName form (msUPN) needs to be supported, but I would prefer to code it in a somewhat more extensible way. Does the attached patch work for you? As a practical way of Yes it does. My only question (and comments bellow) is about passing the oid rather than nid through the functions. I can see the string id-on-dnsSRV used twice in the patch in call OBJ_txt2nid and twice in call OBJ_txt2obj as well when ideally all which should be needed one OBJ_txt2nid(id-on-dnsSRV) and one OBJ_create if not found -- the rest could be done by comparing integers (nid). Unless I'm missing something about the oid/nid interaction. Ah, now I see it -- you look at the semantics of oid to compare value-type so nid would not be enough. How about just passing char * and doing all the mapping logic including possible OBJ_create in parse_otherName_value? My goal here is to have all the hard work of determining the semantics isolated in one place. Please see patch attached. Hi Kaspar, please could you find some time to review this patch? I can say that both proposed patches (your and Jan's) are equivalent when it comes to implementation functionality. Unfortunately, I don't have the OpenSSL knowledge to comment the differences on technical level, but I would also like to see this functionality in the trunk :). Regards, Jan Kaluza
[PATCH 57044] Use base64url in UNIQUE_ID
Hi, in bug 57044, I proposed to use base64url for UNIQUE_ID. This means that the character '_' shall be used instead of '@', because '@' is not URL-safe. '_' is, and it may be used without percent-encoding in URLs, HTTP headers, or cookie values. What do you think? Does anyone dare to commit the proposed patch (in trunk only) ? Regards, Michael
trunk/modules/http2 built and tested
FYI: just checked in a modules/http2 that takes part in the build process, similar options as mod_ssl --enable-h2 --with-nghttp2=path Tests were removed, so all sandbox/* is gone. Instead, I transformed my git mod_h2 into a repository with just the test setup and cases. If interested, you may find it here: https://github.com/icing/mod_h2_test So far, tested on OS X with event/worker/prefork. I had to make two small changes, one for 421 handling and one for a pool threading issue never observed on 2.4. Added XML for directive description. Did not check in the generated pages, as requested. Again, as newbie in this project, please do not hesitate telling me mistakes or advising me to do things in a different way. Thanks. Cheers, Stefan green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: svn commit: r1690248 [2/2] - in /httpd/httpd/trunk: ./ docs/conf/ docs/conf/extra/ docs/manual/mod/ modules/ modules/http2/ modules/http2/m4/ modules/http2/mod-h2.xcodeproj/ modules/http2/mod_h2/
On Fri, Jul 10, 2015 at 7:45 AM, ic...@apache.org wrote: Copied: httpd/httpd/trunk/modules/http2/h2_task.c (from r1690246, httpd/httpd/trunk/modules/http2/mod_h2/h2_task.c) URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_task.c?p2=httpd/httpd/trunk/modules/http2/h2_task.cp1=httpd/httpd/trunk/modules/http2/mod_h2/h2_task.cr1=1690246r2=1690248rev=1690248view=diff == --- httpd/httpd/trunk/modules/http2/mod_h2/h2_task.c (original) +++ httpd/httpd/trunk/modules/http2/h2_task.c Fri Jul 10 11:45:46 2015 @@ -390,11 +390,12 @@ static request_rec *h2_task_create_reque r-protocol = (char*)HTTP/1.1; r-proto_num = HTTP_VERSION(1, 1); -r-hostname = env-authority; - /* update what we think the virtual host is based on the headers we've * now read. may update status. + * Leave r-hostname empty, vhost will parse if form our Host: header, + * otherwise we get complains about port numbers. */ +r-hostname = NULL; ap_update_vhost_from_headers(r); Looks like your sandbox may have had some unexpected changes?
Re: trunk/modules/http2 built and tested
On Fri, Jul 10, 2015 at 6:57 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: FYI: just checked in a modules/http2 that takes part in the build process, similar options as mod_ssl --enable-h2 --with-nghttp2=path Tests were removed, so all sandbox/* is gone. Instead, I transformed my git mod_h2 into a repository with just the test setup and cases. If interested, you may find it here: https://github.com/icing/mod_h2_test There is a repository, http://svn.apache.org/repos/asf/httpd/test/ for all test resources that aren't part of the httpd tarballs/distribution. It can certainly fit in a new mod_h2/trunk/ tree for the time being; if it were possible to integrate it into http://svn.apache.org/repos/asf/httpd/test/framework/trunk/ that would be excellent, as this is the regression test many of us perform to initially validate potentially breaking changes. I expect the behavior of mod_h2 to degrades over time, absent tests to demonstrate correct behavior.
Re: svn commit: r1690248 [2/2] - in /httpd/httpd/trunk: ./ docs/conf/ docs/conf/extra/ docs/manual/mod/ modules/ modules/http2/ modules/http2/m4/ modules/http2/mod-h2.xcodeproj/ modules/http2/mod_h2/
That was a small surprise, yes. Some checks in trunk did not like r-hostname to still have the port. Am 10.07.2015 um 16:59 schrieb Eric Covener cove...@gmail.com: On Fri, Jul 10, 2015 at 7:45 AM, ic...@apache.org wrote: Copied: httpd/httpd/trunk/modules/http2/h2_task.c (from r1690246, httpd/httpd/trunk/modules/http2/mod_h2/h2_task.c) URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_task.c?p2=httpd/httpd/trunk/modules/http2/h2_task.cp1=httpd/httpd/trunk/modules/http2/mod_h2/h2_task.cr1=1690246r2=1690248rev=1690248view=diff == --- httpd/httpd/trunk/modules/http2/mod_h2/h2_task.c (original) +++ httpd/httpd/trunk/modules/http2/h2_task.c Fri Jul 10 11:45:46 2015 @@ -390,11 +390,12 @@ static request_rec *h2_task_create_reque r-protocol = (char*)HTTP/1.1; r-proto_num = HTTP_VERSION(1, 1); -r-hostname = env-authority; - /* update what we think the virtual host is based on the headers we've * now read. may update status. + * Leave r-hostname empty, vhost will parse if form our Host: header, + * otherwise we get complains about port numbers. */ +r-hostname = NULL; ap_update_vhost_from_headers(r); Looks like your sandbox may have had some unexpected changes?
Re: trunk/modules/http2 built and tested
Am 10.07.2015 um 17:04 schrieb William A Rowe Jr wr...@rowe-clan.net: On Fri, Jul 10, 2015 at 6:57 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: FYI: just checked in a modules/http2 that takes part in the build process, similar options as mod_ssl --enable-h2 --with-nghttp2=path Tests were removed, so all sandbox/* is gone. Instead, I transformed my git mod_h2 into a repository with just the test setup and cases. If interested, you may find it here: https://github.com/icing/mod_h2_test There is a repository, http://svn.apache.org/repos/asf/httpd/test/ for all test resources that aren't part of the httpd tarballs/distribution. It can certainly fit in a new mod_h2/trunk/ tree for the time being; if it were possible to integrate it into http://svn.apache.org/repos/asf/httpd/test/framework/trunk/ that would be excellent, as this is the regression test many of us perform to initially validate potentially breaking changes. I expect the behavior of mod_h2 to degrades over time, absent tests to demonstrate correct behavior. I agree. I was not sure about the test thing and how it's used. That is why I put the tests in a githup repo for the time being. //Stefan
Re: The requested URL /as was not found on this server.
I believe the issue is here: SetHandler example_module It may be the case that the string in request_rec.handler is set to the value from SetHandler in the conf. if (!r-handler || strcmp(r-handler, example-handler)) return (DECLINED); You might try: SetHandler example-handler Seems like the name from LoadModule is the symbol name in the .so, and used to reference the module, not any code within the module. -Mark On Fri, Jul 10, 2015 at 1:20 AM, Prakash Premkumar prakash.p...@gmail.com wrote: Hi, I am writing a simple apache module following the docs in https://httpd.apache.org/docs/2.4/developer/modguide.html#snippets Here's the module code: http://pastebin.com/T1TMfLgC Here's my httpd.conf file: http://pastebin.com/aZBWyNve When I access any URL like localhost/asd I get the following error Not Found The requested URL /asd was not found on this server. Can you please help me fix this ?
protocol negotiation
Some weeks ago the backporting of the ALPN patch was rejected as a more generic approach was asked for. Some hinted that an approach of defining a list of supported Protocols per server/vhost and a general registry for some callbacks where mod_ssl and mod_h2 would work with. This and the 421 return code on mismatching host names are the technical obstacles of backporting mod_h2 to 2.4, it seems. Does someone feel like implementing such a thing? Shall I take a stab at it? How should it best be approached? A separate core module which stores things at its own server config? It needs to fit into 2.4 somehow... Have a nice weekend, Stefan green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: trunk/modules/http2 built and tested
You can do an svn mkdir https://svn.apache.org/repos/asf/httpd/test/mod_h2 svn cp -r1690247 https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ http2/sandbox https://svn.apache.org/repos/asf/httpd/test/mod_h2/trunk to shift that all over to the test tree, perhaps integrate into test/framework/ a bit later on if it's possible. On Fri, Jul 10, 2015 at 10:50 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: Am 10.07.2015 um 17:04 schrieb William A Rowe Jr wr...@rowe-clan.net: On Fri, Jul 10, 2015 at 6:57 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: FYI: just checked in a modules/http2 that takes part in the build process, similar options as mod_ssl --enable-h2 --with-nghttp2=path Tests were removed, so all sandbox/* is gone. Instead, I transformed my git mod_h2 into a repository with just the test setup and cases. If interested, you may find it here: https://github.com/icing/mod_h2_test There is a repository, http://svn.apache.org/repos/asf/httpd/test/ for all test resources that aren't part of the httpd tarballs/distribution. It can certainly fit in a new mod_h2/trunk/ tree for the time being; if it were possible to integrate it into http://svn.apache.org/repos/asf/httpd/test/framework/trunk/ that would be excellent, as this is the regression test many of us perform to initially validate potentially breaking changes. I expect the behavior of mod_h2 to degrades over time, absent tests to demonstrate correct behavior. I agree. I was not sure about the test thing and how it's used. That is why I put the tests in a githup repo for the time being. //Stefan
Re: protocol negotiation
On Fri, Jul 10, 2015 at 10:35 AM, Stefan Eissing
stefan.eiss...@greenbytes.de wrote:
Some weeks ago the backporting of the ALPN patch was rejected as
a more generic approach was asked for.
Some hinted that an approach of defining a list of supported
Protocols per server/vhost and a general registry for some
callbacks where mod_ssl and mod_h2 would work with.
This and the 421 return code on mismatching host names are
the technical obstacles of backporting mod_h2 to 2.4, it seems.
Does someone feel like implementing such a thing? Shall I take
a stab at it? How should it best be approached? A separate core
module which stores things at its own server config? It needs
to fit into 2.4 somehow...
my 2 cents, minimum to get it out of mod_ssl and support h2:
I don't think this should be in a separate module since the idea is
that this is the underlying list of app protocols the server will
speak -- just a new core (as in server/{core.c,protocol.c,request.c})
directive to set the protocol preference order in httpd.conf.
Extending the core_server_config is okay for backport
(apr_array_header_t of protocols supported and requested)
It would also need to track what protocols were supported by modules
at the VH level (I think this just means moving the mod_ssl optional
function for ALPN registration into the core)
It would need an API for a module like mod_ssl to tell the core the
protocols a client advertised, per-connection.
The core also probably needs to be the one that determines the one
negotiated protocol from the stuff above.
Finally, at least mod_ssl needs to know what was negotiated. A new
hook to tell anyone interested what was selected seems like overkill,
maybe mod_ssl just runs wherever it already does and calls some method
to get at the negotiated application protocol (based on conn_rec)
Re: [NOTICE] Intent to TR 2.4.16 next week
If you are hung up today, I'll go ahead and roll early this evening. Looks like zero churn for the past couple weeks, a bit of bug fixing and diagnosis, so looking rock solid. On Jul 9, 2015 8:16 AM, Jim Jagielski j...@jagunet.com wrote: Considering the amount of churn, I will TR tomorrow am (Friday) to give 2.4 some time to settle and for people to test/review before we burn another tag :) On Jul 8, 2015, at 8:58 PM, William A Rowe Jr wr...@rowe-clan.net wrote: It appears that STATUS has been effectively resolved on both branches, nothing significant that doesn't alter APIs/Directives in a significant way is ignored, and we seem to be at a stable point for a TR. One nice patch from Eric could use a vote/backport, but it is anything but critical. Jim, please let us know if you plan to tag 2.4.16 Thursday morning? Otherwise, I'll proceed to TR in the early afternoon as I TR 2.2.30 as well. With very sparse number of testers, I'm unwilling to wait for Friday, particularly since patch review has been particularly sparse in the community over the past month or few, and my own opportunity to review and vote on both candidates is limited by travel for a friend's wedding. Announcing these Monday - or Tuesday on the outside if there aren't sufficient votes over the weekend, seems like a good thing for our users. Bill
[VOTE] Release Apache httpd 2.4.16 as GA
The pre-release test tarballs for Apache httpd 2.4.16 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.16 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. NOTE: The *-deps are only there for convenience. Thx! PS: Hopefully, 4th time's the charm!
