Re: sporadic 500 errors with 2.4.55
On 2023-01-18 13:40, Stefan Eissing via dev wrote: Thanks for the logs. That was really helpful. If you can build a 2.4.55 yourself, could you try the following patch? Yep, the patch fixed it. I don't see any 500 errors anymore. The 500 in the access log happens when a client RST (resets) a stream before the response has really started. The HTTP/2 processing of this is totally fine and as should be. We just have an entry in the access log where there should be none. It's also generating a 500 that can be seen by the server. e.g. I found this by using a php file as an ErrorDocument that sends an email when encountering a 500. Thus this 500 is not only in the logs but must also trigger the ErrorDocument 500. Those are also gone now. Thanks a bunch for fixing this. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: sporadic 500 errors with 2.4.55
On 2023-01-18 06:43, Stefan Eissing via dev wrote: In that case, maybe your could run the 2.4.55 mod_http2 with "LogLevel http2:debug" until some 500s show up. That would be very interesting to analyze. You can mail/link me such a log confidential atste...@eissing.org, if you like. I've setup a test VM and was able to reproduce the problem. However, in my test I got only one 500 error, but I do have an access log and an error_log set to http2:debug. Do you want the 2 logs or is Andreas' log sufficient? Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: sporadic 500 errors with 2.4.55
These are all good questions.
On 2023-01-18 02:04, Ruediger Pluem wrote:
1. As you suspect h2 have you tried running 2.4.55 without mod_http2?
No.
2. As you see the 500 errors only in the access log are they only for HTTP/2.0
or also for other protocol versions?
I believe so, but after downgrading the logs were wiped by rotatelogs.
Unfortunately rotatelogs does not append, but always truncates the logs at
server start.
3. Do you use %L in your access and error log which eases correlating the logs?
No. I am using the following:
ErrorLogFormat "[%{cu}t] [%-m:%l] [pid %P] [%7F] %M"
LogFormat "%h %u [%{%F %T}t.%{usec_frac}t %{%z}t] \"%r\" %>s %b
\"%{Referer}i\" \"%{User-Agent}i\"" standard
LogFormat "%v %h %u [%{%F %T}t.%{usec_frac}t %{%z}t] \"%r\" %>s %b
\"%{Referer}i\" \"%{User-Agent}i\"" vhosts
4. What loglevel do you use and what would be the highest one you could set
given the nature of the error (sporadic) and the
traffic on your side?
I am just using the default log level. (LogLevel warn)
I have downgraded and I won't upgrade to 2.4.55 anytime soon. At least not
this server. I rather depend on this server and the implications are too
great. I might be able to setup a test server in a VM, but can't say if I will
be able to reproduce it there. However, I wouldn't be able to set a debug log
level on my prod server anyway.
2.4.54 works perfectly fine. I don't get any errors and the performance is
subjectively better. Thus I will stick with that version for now.
I will be heading to bed soon. It's rather late (or early) already in EST. ;-)
Cheers,
K. C.
--
regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
signature.asc
Description: OpenPGP digital signature
Re: sporadic 500 errors with 2.4.55
Additional info: I reverted back to 2.4.54 and the errors are gone. It also seems that the responses are snappier. The perf observation is subjective of course. Without any proof I suspect that there is some sort of contention/lock issue with h2 that might also result in a 500 now and then due to maybe a race condition? This his highly speculative of course. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
sporadic 500 errors with 2.4.55
After I have upgraded to 2.4.55, I get internal 500 errors now and then. The strange thing is that they do not show up in the error log, but only in the access log. Another weird thing is that they seem random and happen with random files, like the favicon.ico I don't do any redirects so it's not a rewrite engine bug or misconfiguration. I am sorry that this bug report is so vague, but I don't have a record in the error_log, nor do I actually see the error when browsing to that web server. I've only noticed this because I get emails when someone encounters a 500 error. But maybe someone has seen this as well, in which case you have at least the info that someone else experiences this also. It has happened about 30 times in the last 4 hours. It's intermittent and makes no sense. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: [VOTE] Release httpd-2.4.50-rc1 as httpd-2.4.50
On 2021-10-01 10:40, ste...@eissing.org wrote: > https://dist.apache.org/repos/dist/dev/httpd/ Hmm, something is off. I can see the .htaccess file in the directory listing. I suspect a directive is missing in the config. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: iOS 14 / macOS 11 and HTTP/3 support
On 2020-06-27 08:48, Luca Toscano wrote: > the challenges are the same one discussed in your previous email > thread These are all valid points, although in the end absolutely irrelevant. It's very easy and it doesn't take a genius to figure this out: as soon as there is a web server out there that can do HTTP/3, people will just use that one instead. All the excuses (even though I do understand how valid they are) won't change a thing. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: 2.4.next coming?
> You are correct that the commit bit is required as noted here: > http://httpd.apache.org/dev/release.html#who-can-make-a-release > ... but we sure do look for contributors on a regular basis and offer > committership for folks participating in the community and improving the > health of the project. There are lots of ways, including things that don't > touch code at all, that one can participate :-) >> Maybe you could just jot down a few notes while you are doing >> it. Over time, it could evolve into a release manual... > I cannot claim credit for the initial work here: > http://httpd.apache.org/dev/release.html#how-to-do-a-release Thanks for the info. > P.S. > We usually prefer to chat on the dev@ list. If you're OK with that, please do > consider sharing your reply there. If you are wondering about the process, > there's a good chance someone is as well. Feel free to include my message, > too. Yep, this was not on purpose. The httpd mailing list does not provide a reply-to: header using the mailing list's address. So this can happen. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support
On 2019-09-27 11:47, Eric Covener wrote: > I don't think market share is a big motivating factor for active contributors. Maybe not, but I remember a discussion a while back on this list that had to do with features vs stability, about market shares and why other web servers are gaining. > HTTP/3 would be a lot of work, a lot of shoehorning into HTTPD, and > likely be de-stabilizing for quite some time. There is > simply nobody (seemingly) working on it. I get that, I was simply saying that I didn't understand why there wasn't a plan. That's all. I also do understand that this might be a highly complex topic, especially since it will touch many components. I'm very grateful that Stefan took the initiative to get h2 into httpd. > HTTPD is great and familiar to lots of people, but HTTPD'S age brings > a lot of baggage. Lots of other great servers have much > less baggage and currently have much more commercial interest and buzz. I've been using Apache httpd since the early days and I won't be switching to another web server. But the "baggage" can't be the reason for stagnation. A web server's main functionality is to serve web pages. If the protocol evolves so must the server, otherwise the server will be obsolete at one point in the future. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support
On 2019-09-27 10:40, William A Rowe Jr wrote: > This answer \V/ (from Stefan) below. More explanation follows... Thanks Bill, your explanation certainly helped to shed some light on this. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support
On 2019-09-27 03:00, Stefan Eissing wrote: > I know of no plans to implement HTTP/3 support in Apache httpd. I'm sorry, but this seems rather strange to me. So what's the idea behind this decision (or better said the lack of a plan)? "Let's wait until other web servers implement it and wonder why they are gaining more market share?" I'm not mocking anyone, this is a honest question. I also don't understand the statement: > I think there are plenty resources online where you can find an answer to > your question. (as an answer to "What’s the incentive to add it? ") In fact a web search does not yield any useful results. Furthermore the OP most likely meant "what incentive would be required to add it". Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: Fwd: [Bug 62590] performance drop after moving from apache 2.2 to apache 2.4
Hello, On 2018-08-28 10:54, William A Rowe Jr wrote: > As we unwind various regressions and breakage, one non-lethal but > somewhat horrid report stands out. Eric correctly tied it to the patch > applied for https://bz.apache.org/bugzilla/show_bug.cgi?id=62590 in the > 2.4.24 timeframe. I'd like to comment on the last entry in the ticket: --- For 100% clarity, this was observed with the version of ab shipped with 2.2.34, or the version shipped with 2.4.24? It should be obvious that ab has also undergone some enhancements and changes for support of TLS, and the two different versions are expected to produce two different results. --- It shouldn't matter which version was used as long as the same one was used for both tests. According to the ab output, Paolo used the same version for both tests: This is ApacheBench, Version 2.3 <$Revision: 655654 $> Unfortunately this output is useless unless you know the revision numbers by hart. It looks like it is a 2.2 version, but I could be wrong. (A 2.4 version has a revision around 1826891.) Note to devs: it would be great, if ab could use the same version numbers as the server. ;-) Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: TLSv1.3
Hello,
On 2018-03-29 04:16, Stefan Eissing wrote:
> Besides, except for data center setups, Apache will be used *only*
> with https: (and http: redirects to https:) very, very soon. That
> shifts the average expertise of an admin setting up a https: site.
This statement makes me a bit nervous. Are you saying that there won't
be a way to use Apache with http anymore? (Since I don't know what a
data center setup entails that is - new directive, http only setup, ...)
Also, the 'will be used' part is a bit puzzling. This part rather
suggests that all users will magically only use https from that point
forward. Or was it meant as "Apache will only use https anymore"?
I'm basically using https anyway, however there are connections that
*must* be plain http, e.g. the ACME challenge. I like to use my own
scripts for maintaining the certificates thus I am not using the Apache
module, which further means that I must have control over Apache's http
setup.
I'm doing something like this:
ServerName HOSTNAME:80
Alias "/.well-known/acme-challenge/"
"/COMMON_DIR/acme-challenge/.well-known/acme-challenge/"
Require all granted
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/.*
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L,R=301]
ServerName HOSTNAME:443
# Your "real" configuration here
Can you please elaborate on your above statement and clear that up for me?
Cheers,
K. C.
--
regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
signature.asc
Description: OpenPGP digital signature
Re: New ServerUID directive
On 2018-02-06 05:13, Yann Ylavic wrote: > Sorry for what is probably (my) bad english, "fixed" meant "the same > after restart (or stop/start)". Right, but isn't the virtual host's server name/port config after the restart the same as well? Why do you need a new separate unique identifier? And should you ever change the port number and/or the virtual host's server name, then this virtual host won't be the same after a restart anyway. Either I'm missing something here, but I still don't understand the reason for a unique identifier, when you already have one. Or at least one that can be used from a combination of several fields in the server struct. What am I missing? -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: New ServerUID directive
On 2018-02-01 12:54, Yann Ylavic wrote: > I have this patch (attached) floating around that allows users to > configure a *fixed* UID for each vhost. What do you mean by *fixed*? I thought the virtual host itself already has to be unique. As far as I know, I can't have two virtual hosts with the same hostname and port. So why is it necessary to create another unique id? Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: We have soon 5 SVN repo's
On 2017-11-05 06:08, Graham Leggett wrote: > Your desire for us to host your private feature branches, and hand out logins > to our infrastructure to people who openly profess not to care about our > projects is not something I would like to see encouraged. You still do not understand what I am saying. And you are twisting my words. Maybe you are referring to the following: --- Commit the patch to the 2.4.x branch (as a new feature or patch branch) and send a PR. (X reviewers are required, and boom it gets merged. Don't forget all the nice CI that can be triggered before or after the merge.) --- Where do I say that I want you to host my private feature branches? git is distributed and decentralized. I create a branch locally and send a PR (which could trigger a CI run on your repo as part of the PR). But you are not wrong. Core developers should have the possibility to create feature and patch branches on the remote (main) repo (in case of git). This does not mean that I want to push my branches to the main repo as a one time or casual contributor. Theoretically you could setup access control in a way that people can't push to certain branches, and/or are only allowed to create branches as subbranches and whatnot. The possibilities are endless. But this is another story and I never wanted to discuss this in the first place. Also, I never said I do not care about your projects. Do I really have to explain how a statement refers to a quote? --- Graham: you expressed a definite unwillingness to follow our process, Graham: which starts by creating a patch for trunk. KC: I don't really care, because KC: I don't have time to contribute to this project anyway. --- This means I currently don't care about the process, because I don't have the time to contribute. Then 2 sentences later I also wrote the following: --- If I really wanted to start writing code (new features, internals, ...) for httpd, I'd be willing to learn the process. --- I also never said I wanted login credentials. I said the current system requires a developer to have login credentials. e.g. with git and a PR concept, there's no need to have login credentials (but CI can still be used) Anyway, I'm done. You are either not reading my mails in context or ignoring what I'm writing. Like the process this conversation is too tedious for me. -- regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: We have soon 5 SVN repo's
On 2017-11-04 19:18, Graham Leggett wrote: > No, you expressed a definite unwillingness to follow our process, > which starts by creating a patch for trunk. I think you misunderstood, at least partly. I don't really care, because I don't have time to contribute to this project anyway. I was just talking about why others _might_ not want to. Why would I do that, you may ask. The topics of VCS and release strategy came up several times during the past years and the discussions never really changed anything. If I really wanted to start writing code (new features, internals, ...) for httpd, I'd be willing to learn the process. However, I would not do the same for patches. If I were to find a bug and had a patch for it, I'd not want to follow your process. I'd send off the patch to the list and you can do whatever you want with it. I would not be wasting my time to learn a tedious process for submitting a patch. And I am not talking about core developers, but people who find something, fix it, and want to contribute their fix back to the project. A lot of projects live because of these casual contributions and Apache httpd would attract more devs for these kind of contributions with an easier process. That's all that I'm saying. >> Yes, most projects have their own conventions and yes, I tailor my >> contributions towards their processes as well. > Except in this case. Yes and no, as mentioned before there's a difference between core developer, casual contributor, and one time contributor. On the other hand, my hint towards CI was not without reason. I do not know your current CI pipeline or if you even have one, but working with git and branches, triggers and plugins makes the process very convenient. Although I'm sure you can get this done with SVN as well. How often was a release thrown out because some tests failed after tagging? If you used CI and after every commit or a merge to a certain branch the entire test suite were triggered (on all OSes/systems), wouldn't that make your job a lot easier? Just saying... ...not forcing anything on you... (To be clear, this is my opinion, not telling you what to do.) > Unfortunately you’re pointing out the obvious. There are a number of > ways of doing things, and projects make different decisions to meet > their needs and objectives. That way is sometimes not your favoured > way. If we constantly changed our process, we’d not serve our > community, and ultimately serving our community is the point. As you mentioned before, you haven't changed anything for the last 2 decades, so talking about changing something constantly is a bit of stretch, isn't it? I've worked on IBM DB2 were coding a line item took maybe a few days, but getting it into the source tree took up to 6 or 8 weeks. That process was necessary with 2,500 developers and 40,000,000 lines of code. So, I do understand that certain processes make sense, some others are just bureaucracy, and others exist because people just do not want to change them. I can also tell you that I had patches available for other projects and I did not contribute them, because I would have had to create yet another userid for another system, or sign up for another forum, or subscribe to another mailinglist - just because there was no way to do a fire-and-forget method of submitting a patch. Please note, there are differences in contributions and how much a dev is willing to do for each of them. "I fix something and they want me to jump through hoops? Sorry, not with me." - This attitude is quite common, especially if it is a one time contribution. -- regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: We have soon 5 SVN repo's
On 2017-11-04 18:25, Graham Leggett wrote: > If you aren’t willing to do the four things you’ve mentioned above, > your code has pretty much disqualified itself from consideration, and > what you want is largely irrelevant. This attitude is exactly the reason why Apache is losing marketshare against Nginx. > We have a development and release process that has been in place and > served us well for almost two decades, and most of the popular > release processes that are in vogue today are just more complex > versions of our existing workflow. I would recommend learning how our > release process works before suggesting it be replaced (with a > workflow not unlike our existing). Seriously? You must be joking. Also, I'm not the one who suggested to replace it, but pointed out a few arguments for git, which was suggested by Stefan Priebe. Or the be exact, he asked "why not git?". > Every project I’ve been involved in, from Apache C projects to Maven > based Java projects, to other open source projects like freeradius > and gstreamer, has its own set of conventions and ways of doing > things. In each case I tailor my contribution to fit the existing > project, I don’t expect the project to rearrange itself around me. Yes, most projects have their own conventions and yes, I tailor my contributions towards their processes as well. However, there are projects, which processes are too extrem and tedious and I don't contribute because of them. I did not suggest to replace your precious work flow, I only showed up why people _might_ be put off by it. -- regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: We have soon 5 SVN repo's
On 2017-11-04 11:43, Eric Covener wrote: > I'd be surprised if it helped someone who felt overwhelmed by the > existence of 5 branches in SVN (no offense intended). I agree to disagree. Graham's long explanation which still doesn't cover certain scenarios is for sure a reason why not more people contribute to the project. Let's say I have a patch for the current version of Apache: 2.4.29. What now? I have to get it first into 2.5.0 or trunk, which might not even be compatible? So I have to figure out how the code in trunk works? Then I have to do what? Learn SVN and how to use the STATUS file? I can't even commit to a branch (let alone the fact that feature banches do not exist) without a userid on svn.apache.org. All I want to do are 2 steps: Commit the patch to the 2.4.x branch (as a new feature or patch branch) and send a PR. (X reviewers are required, and boom it gets merged. Don't forget all the nice CI that can be triggered before or after the merge.) While I still learned how to use CVS and SVN (which I also used in personal projects and hated btw), used other ones like clearcase for huge projects (like IBM DB2), the new generation of developers did not and - believe me - they don't want to. (I definitely wouldn't want to, if I had ever be involved in a project that used git.) A move to git doesn't mean that this project will gain hundreds of new developers over night, but it might give you a chance to streamline the current development *and* release process. The rest will follow. -- regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: [VOTE] Release Apache httpd 2.4.28 as GA
On 2017-10-01 18:08, Rainer Jung wrote: > Since I can only observe it with prefork in combination with http2 which > is not a good combination in any way, I am not too concerned. Still it > could be useful to understand whats going on. How can this even be? http2 is automatically deactivated when mpm is prefork. Stefan added this in 2.4.27. There is no h2 with prefork anymore. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: [VOTE] Release Apache httpd 2.4.28 as GA
On 2017-09-28 09:51, Jim Jagielski wrote: > Personally, I don't think the age or heritage of the build-logic is the issue, > but rather a lack of people *really* testing 2.4.x until a release is tagged. > It's for that reason that I tend to pre-announce a T well in advance of > actually > DOING the T so that people can test HEAD in hopes that the tag will already > have had some good testing beforehand. I have a question. Why are you tagging a release and do testing? Most of the time a problem is found and a new release is tagged and it starts over (I think the max was a 3 or 4 patch level jump). Why not tagging an RC? People test the RC. When all is ok, the RC is released. If not a new RC is tagged. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: svn commit: r1802336 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml
On 2017-07-24 13:42, Jacob Champion wrote: > Any chance this is because of the hang I mentioned? It could be, but this doesn't really change anything. If the setting enablereuse can change the behaviour of web applications and introduces hangs and timeouts, it is time to rethink the implementation. Maybe there should be a way to communicate between fcgi backed and proxy, so that the request is not lost but sent on a previous established connection. This setting should improve performance, not make it possible to have failed requests due to timeouts and/or hangs. -- regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: svn commit: r1802336 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml
On 2017-07-24 13:29, Jacob Champion wrote: > I have still not been able to reproduce the "messed up POSTs" that other > people are reporting with UDS+enablereuse. In my case it screwed up the POST request by not doing what should have been done with the request. In the end the request was lost. (due to timeout, not processing it, or for whatever reason) It did not mess up the content of the request, if that's what you're thinking. The request just did not get through. After removing the Proxy section with the enablereuse option, all was good again. -- regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: Apache reverse proxy
On 2017-07-21 15:28, Stefan Pernar wrote: > Thanks everyone. Got it done with nodejs, express and http-proxy. You know, it is utterly useless to say you have fixed it without telling people how you did it. -- regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: 2.4.27
On 2017-07-18 14:25, Eric Covener wrote:
> Argh, not right, missed the other return stmt.
>
> It seems like proxy_trans will return OK to translate_name() and not
> let mod_rewrite in non-perdir run at all. It is rigged to run before
> mod_rewrite.
Ok, it seems that my rewrite issue has gained a bit of attention, thus I
will explain it now in more detail (otherwise people don't know what I
am actually talking about):
Options FollowSymLinks
AllowOverride None
ErrorDocument 404 /404.php
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^\.]+)$ $1.php [NC,L]
Require all granted
With mod_php I got the 404.php error page when going to:
https://example.com/te
With mod_proxy_fcgi I get a "File not found." error in the browser and
the following is in Apache's error_log:
[proxy_fcgi:error] AH01071: Got error 'Primary script unknown\n'
However, I get the 404.php error page, when going to:
https://example.com/te.t
https://example.com/te/
(So it works partly with proxy_fcgi.)
I'm still investigating why that is. I'm a bit pressed for time that's
why I haven't been able to look into it in more detail.
I have to setup a VM to debug this further, but IMO this is not ok.
In both cases the rewrite should work the same way.
My handler cfg looks like this:
SetHandler "proxy:unix:/var/run/php7-fpm/sample.sock|fcgi://sample"
A rather simple use case, yet the bahaviour is different. Don't get me
wrong, but it shouldn't behave differently.
--
regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D
Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D
/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
Re: 2.4.27
On 2017-07-18 12:54, Yann Ylavic wrote: > You should probably re-check with latest 2.4.27, where some > regressions with regard to php-fpm (since 2.4.20) where finally > addressed (see https://bz.apache.org/bugzilla/show_bug.cgi?id=61202). I did. 2.4.27 fixed a proxy_fcgi problem and nextcloud: https://github.com/nextcloud/server/issues/5660 It didn't help with the rewrite issue. -- regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: 2.4.27
Hi David, Thanks for your reply, but I have already established in my previous email what the order of evaluation is. Have you seen this sentence? >> So ProxyPass has precedence over other directives. It is evaluated >> first. This can lead to a number of problems. On 2017-07-18 09:33, David Zuelke wrote: > You need to use SetHandler. You can't use rewrites with ProxyPass > because of the order of evaluation. I am. I have never used anything else but SetHandler. I think I explained in the mail you replied to what I think of ProxyPass. > Further questions should be taken to the users list though, as this > one here is for development of httpd... I believe you did not read my email or read something into it. This is not a user question. I know how to use mod_rewrite. I stated that mod_rewrite behaves differently when using mod_php and mod_proxy_fcgi. This sounds more like a bug, because it really shouldn't. I used rewrite with mod_php. It worked. Then I switched to mod_proxy_fcgi. Now it does not. So why is that? I also mentioned I have to debug it further. -- regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: 2.4.27
On 2017-07-17 03:50, Luca Toscano wrote: > mod-proxy-fcgi is the preferred solution over mod-fcgi, and we have > documentation about it. Any specific reason to use libapache2-mod-fcgid? > (asking for curiosity and/or to decide if a doc update is needed :) I am using mod_proxy_fcgi exactly for that reason (stated on https://wiki.apache.org/httpd/php). But the documentation (https://wiki.apache.org/httpd/PHP-FPM) is IMO a bit off. > Can you please be more specific? What errors do you see? In case please > open a task in bugzilla so we'll be able to debug it :) Even according to the documentation for mod_proxy_fcgi, UDS does not support connection reuse. In my case it broke POST requests. I then googled and found a bunch of articles and stackexchange entries that suggested to remove the enablereuse=on option from the Proxy section. Only after removing the Proxy directive completely, everything started to work as expected. Except from the mod_rewrite issue I experience. I'm still debugging it, but mod_rewrite behaves differently between mod_php and mod_proxy_fcgi, which should not happen at all, since rewrite shouldn't care or know about the backend. I also googled and found a few entries, none of which helped me: https://stackoverflow.com/questions/44054617/mod-rewrite-in-2-4-25-triggering-fcgi-primary-script-unknown-error-in-php-fpm http://www.coders.pro/2017/01/qq-htm/ > Using ProxyPassMatch is not only dangerous, it also has precedence over > a FilesMatch directive, which in turn limits your ability to restrict > access to certain resources. At least that was the case a couple of > years back. > > Dangerous in what way? Can you please be more specific and/or add examples? I'm sorry, my bad. I should not have generalized it. ProxyPass and ProxyPassMatch _can_ be dangerous. I see 2 main issues: 1) The match part can be set too wide, which could allow php-fpm to interpret the wrong file. 2) The documentation also states: Warning: when you ProxyPass a request to another server (in this case, the php-fpm daemon), authentication restrictions, and other configurations placed in a Directory block or .htaccess file, may be bypassed. So ProxyPass has precedence over other directives. It is evaluated first. This can lead to a number of problems. Anyway, as long as you are aware of it, the impact can be minimized. Yet I believe it is too dangerous for the average Joe. -- regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: 2.4.27
On 2017-07-16 18:41, James Cloos wrote: > And I've not found any *working* documentation on how to switch to using > php7.0-fpm and libapache2-mod-fcgid. Yea, the documentation on https://wiki.apache.org/httpd/PHP-FPM is also flawed. e.g. if you use the proxy option enablereuse=on in a proxy_fcgi setup that uses sockets, you are screwed. The entire setup blows up. Using ProxyPassMatch is not only dangerous, it also has precedence over a FilesMatch directive, which in turn limits your ability to restrict access to certain resources. At least that was the case a couple of years back. -- regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: mod_proxy_fcgi and flush
Hi Luca, On 2017-07-13 13:36, Luca Toscano wrote: > It would be interesting to also know from Helmut a simple (PHP?) use > case to use as a test, so I'll not base my code only on Jacob's example > (that was really useful though!!). I don't have a specific example. I referred to a comment on the proxy_fcgi documentation web page in my first post in this thread. It struck me as odd that flushing was possible with an option for FastCgiExternalServer, but apparently not available in a proxy_fcgi setup. I recently switched my setup to an event mpm with php-fpm and proxy_fcgi. I'm also still working out a few kinks with mod_rewrite which seems to behave differently all of a sudden. When I can't figure it out by reading the debug logs, I will most likely post another question on this mailing list. ;-) IMO the same rules should yield the same results, no matter the backend. Anyway, I'm getting off-topic here... -- regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: 2.4.27
On 2017-07-11 08:55, David Zuelke wrote: > That PHP bug affects parsing of PHP-FPM's config file. It has nothing > to do with the FastCGI interface or its runtime behavior. Nope, it also fixed a web application for me. see https://github.com/nextcloud/server/issues/5660 -- regards Helmut K. C. Tessarek lookup https://sks-keyservers.net/i for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: mod_proxy_fcgi and flush
Hi Luca, Thanks for looking into this. On 2017-07-08 03:51, Luca Toscano wrote: > I checked mod_fcgi as Helmut suggested and it seems to me that the > -flush feature is a simple "flush every data that you receive", so I > tested the following patch with Jacob's php example code and it seems > doing what Helmut asked (please correct me if I am wrong). No, you are correct. But I was merely referring to the comment on the documentation page. But yes, this seems to mirror the "-flush" option that is present for FastCgiExternalServer. > Caveat: I had to set output_buffering = Off in my php-fpm's php.ini > config file. This should be ok, since people who are using output buffering are usually aware that it can influence the app's behaviour. I think that was even stated in the PHP manual somewhere. Although I also remember that there was a section that states that both ob_flush() and flush() have to be called to make flush work with output buffering on. > So if what I wrote vaguely makes sense, we might think about adding a > new directive that enables explicit flushing to mod_proxy_fcgi, so > admins can twist its behavior if needed? As far as I can tell it makes sense, but I haven't gone through the entire proxy code yet. Are you thinking of a directive like ProxyFCGIFlush or an option to the proxy worker: > Completely agree with Jacob, this use case might not be the best one for > HTTP :) As mentioned before, in a perfect world I'd agree. But this option was available with FastCgiExternalServer, thus it should be available with proxy_fcgi as well, especially when proxy_fcgi is the preferred way for Apache >= 2.4. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup https://sks-keyservers.net/i for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: mod_proxy_fcgi and flush
On 2017-07-07 17:50, Jacob Champion wrote: > I'm probably not the person you're looking for; I don't know the > mod_proxy code very well. You may find that my root cause analysis is > completely incorrect. But, if you'd like to bounce ideas off me, go > for it. (As Luca already knows, I can be a little sporadic when it > comes to this sort of thing. Fair warning! :) ) I'm gonna have a look at the mod_proxy and mod_proxy_fcgi code. Who wrote the code in the first place? Maybe I can bug that person with my questions. ;-) Let's see, maybe I'm totally out of my depth anyway. Sometimes it's very hard to chime in, when you haven't been there from the beginning. > #httpd-dev on Freenode is also a place -- very quiet, usually, but I > try to be there when I can. Yea, not a fan of irc. I always find it very frustrating. Asking something, waiting forever, not getting any answers. I'm more into IM. I've noticed that people on IM are more responsive, since they really seem to be online when the status says they are online. Anyway, I don't think that real time chat is necessary, at least not right away. -- regards Helmut K. C. Tessarek lookup https://sks-keyservers.net/i for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: mod_proxy_fcgi and flush
On 2017-07-06 14:54, Jacob Champion wrote: > If I'm honest, my brutally blunt take on it is "stop using HTTP to try > to emulate push notifications within a single response; pretty much > everything in the ecosystem is actively working against you at this > point; responses are designed to be cacheable and deliverable as a unit, > not as multiple pieces; and we've had *real* solutions like WebSocket > for five years now rabble rabble rabble." But I don't actually think > that's going to be the accepted answer. In a perfect world, I'm right there with you, but we've seen (as long as technology has existed) that people twist the way how technology is applied and used. It's hard to convince those people otherwise, especially when most of the time it has been possible to get it to work - somehow. > It probably makes sense to work on a nonblocking architecture for > proxied responses in general. I'm not familiar with that particular code, but would be interested in looking into it. Does anybody volunteer as a mentor? Cheers, K. C. -- regards Helmut K. C. Tessarek lookup https://sks-keyservers.net/i for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
mod_proxy_fcgi and flush
One of the comments on the documentation page of mod_proxy_fcgi (http://httpd.apache.org/docs/2.4/mod/mod_proxy_fcgi.html) mentions an issue with flush: There is just no flush support it seems. I attempt to use PHP flush() and it won't work until you fill up a buffer first, rendering Server Sent Events impossible with proxy_fcgi. It worked very well with "-flush" with mod_fastcgi FastCgiExternalServer. If this is really the case, all web applications that use push notifications won't be working with mod_proxy_fcgi. The wiki page on https://wiki.apache.org/httpd/php also suggests to use mod_proxy_fcgi, but if above is true, this might lead to problems. What is your take on this? -- regards Helmut K. C. Tessarek lookup https://sks-keyservers.net/i for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: 2.4.27
On 2017-07-06 13:09, Reindl Harald wrote: > with removing mpm_prefork support for H2 you kill HTTP2 support for a > lot of production setups which may consider switch to H2 in the future > and for sure not rework there whole configuration but put a proxy like > Trafficserver in front and forget about httpd at this point at all I respectfully disagree. Removing h2 on prefork solves all issues that arise when used in this context. You don't put diesel in your car, when your engine is for regular gas. Why? Because it won't work and might screw up your engine. Same applies to h2 and prefork. -- regards Helmut K. C. Tessarek lookup https://sks-keyservers.net/i for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: HTTP/2 and no-longer "experimental"
On 2017-05-31 11:46, William A Rowe Jr wrote: > If my assumptions above are wrong, ignore this thought... but if > the goal is to drive adoption of our 2.6 implementation of http2, > then simply dropping "experimental" seems unwise. Upgrading > its status from "experimental" (which I read as -alpha at best) > to a "beta" release of mod_http2 in 2.4.26 might be a really good > idea to drive interest in advance of 2.6, while averting a half-decade > long support effort of that specific module on the already five year > old stale branch. This topic is also about perception. Most people won't use http2 in production, if it is marked as experimental or beta. These people might look at other server software instead. How long will people have to wait for 2.6? This is a fair question, because I have no idea what your plans are. But I guess it won't be for a while (timeframe maybe even years?). Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: SSL and Usability and Safety
On 2017-05-02 09:19, Stefan Eissing wrote: > A. "I want my site safe and usable with modern browsers!" > B. "I want a safe setting, but people with slightly out-dated clients should > be served as well." > C. "I sadly need compatibility to some very old clients." It would be great to explain the performance impact per setting. The average Joe has no idea how to run benchmarks and interpret the results. Yet I came across people who used the default settings wondering why it wasn't performing that well. I know, an average Joe shouldn't configure a web server (especially for performance) in the first place, but you wouldn't believe how many companies do not have proper resources. I often heard people complaining that Apache wasn't performing well, which in my opinion was misconfiguration and/or bad default settings. Apache httpd deserves better than the younger generation favouring nginx over Apache because of alleged better out of the box performance. I'm not sure, how much perf difference there is between A, B, and C, but SSL by itself has quite an impact, especially on boxes without the AES CPU extension. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: header file distribution bug - ap_config_auto.h not private
Hello Jacob, On 2017-04-11 17:04, Jacob Champion wrote: > To me, what you've described looks like a bug. > > I have no idea how easy or difficult it would be to remove the internal > config macros from our distributed headers -- it looks like we've been > doing this for a *long* time. And if it's not easy to do without risking > compatibility, I would guess that we wouldn't attempt a fix for 2.4.x. > > See also https://bz.apache.org/bugzilla/show_bug.cgi?id=46578 , though I > don't necessarily agree with the proposed solution there. Thanks for the info. Well, you don't necessarily have to remove them, but they have to be guarded somehow. e.g. pass a define ICOMPILEAPACHE to the build process and only then the generated file is used. This define must not show up in any compile options or apr/apu-config output. This is one way to fix this. Another one would be to split the file into a publc and private part and not distribute the private one. I will have a look at the link you provided. The current situation makes it impossible to use the autotools AC_CONFIG_HEADERS macro in a project that involves Apache httpd. (or at least when you require that include) Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
header file distribution bug - ap_config_auto.h not private
Can anyone please provide some feedback? (no, your bug is no bug. yep, we are looking into it. yep, it's a bug) There's nothing worse than being ignored. Some of the typical autotools defines made it into the current package and they interfere with one's own build process: one example (there are 5 different occurrences): In file included from /usr/local/apache/include/ap_config.h:138:0, from /usr/local/apache/include/ap_provider.h:29, from myfile.c:33: /usr/local/apache/include/ap_config_auto.h:210:0: warning: "PACKAGE_BUGREPORT" redefined [enabled by default] #define PACKAGE_BUGREPORT "" I checked out branch 2.4.x. After running ./buildconf the issue became obvious: grep -r PACKAGE_BUGREPORT * configure:PACKAGE_BUGREPORT= configure:PACKAGE_BUGREPORT configure:#define PACKAGE_BUGREPORT "$PACKAGE_BUGREPORT" include/ap_config_auto.h.in:#undef PACKAGE_BUGREPORT modules/http2/h2_config.h:#undef PACKAGE_BUGREPORT modules/http2/h2_version.h:#undef PACKAGE_BUGREPORT srclib/apr/configure:PACKAGE_BUGREPORT= srclib/apr/configure:PACKAGE_BUGREPORT srclib/apr/configure:#define PACKAGE_BUGREPORT "$PACKAGE_BUGREPORT" srclib/apr/include/arch/unix/apr_private.h.in:#undef PACKAGE_BUGREPORT ap_config_auto.h is not a private header that is excluded from the dist tarball. The header file ap_config_auto.h should never, ever be distributed. (Or included from another header file unless Apache httpd itself is built.) There are a few options to fix this, but I don't know how you want to handle this. Since you work with the build system every day, I'm sure you know the best way to implement a fix. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://sks.pkqs.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madnessawait thee at its end. */
header file distribution bug - ap_config_auto.h not private
Some of the typical autotools defines made it into the current package and they interfere with one's own build process: one example (there are 5 different occurrences): In file included from /usr/local/apache/include/ap_config.h:138:0, from /usr/local/apache/include/ap_provider.h:29, from myfile.c:33: /usr/local/apache/include/ap_config_auto.h:210:0: warning: "PACKAGE_BUGREPORT" redefined [enabled by default] #define PACKAGE_BUGREPORT "" I checked out branch 2.4.x. After running ./buildconf the issue became obvious: grep -r PACKAGE_BUGREPORT * configure:PACKAGE_BUGREPORT= configure:PACKAGE_BUGREPORT configure:#define PACKAGE_BUGREPORT "$PACKAGE_BUGREPORT" include/ap_config_auto.h.in:#undef PACKAGE_BUGREPORT modules/http2/h2_config.h:#undef PACKAGE_BUGREPORT modules/http2/h2_version.h:#undef PACKAGE_BUGREPORT srclib/apr/configure:PACKAGE_BUGREPORT= srclib/apr/configure:PACKAGE_BUGREPORT srclib/apr/configure:#define PACKAGE_BUGREPORT "$PACKAGE_BUGREPORT" srclib/apr/include/arch/unix/apr_private.h.in:#undef PACKAGE_BUGREPORT ap_config_auto.h is not a private header that is excluded from the dist tarball. The header file ap_config_auto.h should never, ever be distributed. (Or included from another header file unless Apache httpd itself is built.) There are a few options to fix this, but I don't know how you want to handle this. Since you work with the build system every day, I'm sure you know the best way to implement a fix. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://sks.pkqs.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madnessawait thee at its end. */
Re: SHA-256
Thank you for the response. On 2017-02-24 23:45, William A Rowe Jr wrote: > They are useful for file completeness/error checking only. I'd agree > there is zero purpose in retaining SHA1 when SHA256 is in place. Unfortunately a lot of people do not know this. They compare the hashes instead, either because they don't understand the background, don't have gpg installed, or think checking the hashes is the same as verifying a signature. > And SHA256 is a means to authenticate how, exactly? > > We provide .asc pgp signatures exclusively for that purpose. I agree, gpg is the only way to check the authenticity of a file. However, people who use hashes to do this (for reasons I previously mentioned) are in a lot safer spot, because it's most likely impossible for an adversary to create a collision. I just didn't understand why there would be a reason for other hashes, if there was as sha-256 hash available. Even on legacy systems I've seen implementations for sha256. Thanks again for your answer. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: SHA-256
On 2017-02-24 12:52, Jim Jagielski wrote: > I think we should start, in addition to "signing" w/ md5 and sha-1, > using sha-256 as well. I have a question: why are you still using md5/sha1 for generating file hashes in the first place? Noone with knowledge of hashing algos would use these hashes to validate a file's authenticity. Bottom line is that you lull people into a false sense of security by providing md5/sha1 hashes. People, who don't know that these algorithms have been broken already, might think that they are safe (by checking the file against the md5 hash) while in reality they are not. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: ERR_SPDY_PROTOCOL_ERROR - additional info
On 2017-01-02 10:50, Stefan Eissing wrote: > Are these public facing servers? Do you have low traffic instances where to > enable super-verbose log level and make a test request? Of interest would be Yes, they are and that's why I had to fix the issue right away. I deactivated h2 so that people could reach the subdomains again. The strange thing is that it did not happen on all subdomains. As I said, the error even happened on an Alias. e.g.: server.com worked server.com/test did not work > LogLevel http2:trace2 > LogLevel ssl:trace2 > LogLevel core:debug > > That log should then give an idea of what is going on. Thanks. Ok, let me create a few dummy subdomains. Hopefully the problem is reproducible and I can get you the data you need. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: ERR_SPDY_PROTOCOL_ERROR - additional info
On 2017-01-02 04:58, Stefan Eissing wrote: > You get the errors using Chrome? What does Firefox say? On Firefox I only got some unspecified error (the page was not rendered). That's why I switched to Chrome to get at least some info. > There is one new feature in 2.4.25, off by default, that causes such > errors with Chrome. The Chrome bug report has status "fixed", not > sure when it will be released > (https://bugs.chromium.org/p/chromium/issues/detail?id=662197). Nope, this error happens with all browsers. > As I said, this behaviour is off by default for this reason. It is > changed by directive "H2EarlyHints". > > But maybe it's something totally unrelated to this. Are you able to > reproduce this on a non-production server of yours? Unfortunately I don't have another Linux server with the same configuration. I could try to create a few dummy sub domains and see if it happens again. But I still need info how to debug this any further. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
ERR_SPDY_PROTOCOL_ERROR - additional info
I'm sorry that the previous mail was so short, but there are no error messages in the error log. It happens on several subdomains and for aliases within the same domain, which makes no sense to me, especially since I never came across this problem with the previous httpd version. I'm using the following directive: Protocols h2 http/1.1 I had to deactivate h2 altogether, because a lot of subdomains and aliases errored out and were not reachable. I could have also reverted back to 2.4.23, which I will probably do in a couple of days. I couldn't do any problem determination on my production server. I had to make it work asap. I just wanted to mention that there's something off with h2. Since I only upgraded httpd from 2.4.23 to 2.5.25 w/o changing any configuration files, it must be a problem with the current h2 implementation. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
ERR_SPDY_PROTOCOL_ERROR
After upgrading to 2.4.25, I get ERR_SPDY_PROTOCOL_ERROR on several subdomains and even for Aliases within one domain. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: bug with SSLVerifyClient?
On 2016-11-24 03:33, Plüm, Rüdiger, Vodafone Group wrote: > I agree that it should work with current TLS versions, but I have current no > time to > dig further. At least I know now that I'm not off when I say: it should work. That's why I asked here on the dev list, because people who know the code might have an idea where the problem is right away. Maybe somebody else will be able to answer my question or tell me how to fix this. > As it is changed in the SPEC it is a design problem, otherwise just the > software > implementing it would need to be fixed. That was my point actually. Fixing the design makes no sense, if the implementation sucks. It's not the first time though that just all implementations are at a fault. That's why I asked, I just didn't know. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: bug with SSLVerifyClient?
On 2016-11-23 14:30, Ruediger Pluem wrote: > You can still have that if you configure SSLVerify on virtual server > layer, Right, no renegotiation necessary in that case. Makes sense, thanks. > but not on directory level. Well, apparently I can't have that now either. :-( >> is functionality removed in new protocols? > As far as I understand renegotiation has (and definitely had in the > past) serious security issues. Hence it is removed. Ok, just out of curiosity: was the design flawed or the implementation? Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: bug with SSLVerifyClient?
On 2016-11-23 13:43, Eric Covener wrote: > In your desired config, the initial handshake happens with > SSLVerifyClient=none, so no client certificate is requested so none > can be sent by the client. > The initial handshake completes, then a HTTP request is received that > maps to /dir > Now Apache has to honor your section, and a change to > SSLVerifyClient from none to optional requires a new handshake to > request a client certificate. I see, thank you for the explanation. It still does not explain why it doesn't work though. It should, right? At least according to the documentation. But you also mentioned that this scenario won't work with TLS 1.3. Does this mean you can only have either an auth schema (user/password auth) or a client cert with TLS 1.3, but not both at the same time? Since when is functionality removed in new protocols? Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: bug with SSLVerifyClient?
On 2016-11-23 12:36, Eric Covener wrote: > * I didn't think SSLVerifyClient's data was ever implicitly used in > lieu of basic auth, this gave me pause in the quoted sentence > * The thing to look for here would be whether your request triggers an > SSL renegotiation or not, and if in that 2nd handhsake there is a > certificate request from the server. > * These configs won't work when TLS1.3 arrives because there is no > renegotiation. Why would there be a need for renegotiation? In my scenario SSL is always used. If the client has a cert installed, the cert should be used. Otherwise the standard/basic auth should be used (still over SSL). What is troubling is the fact that it works in a virtual server context, but not in the directory context. There are configurations available that either allow you to use a cert or a basic (or 3rd party) auth mechanism. And I'm using them in my virtual server context, but now I want it to work in the directory context as well. It is in the documentation after all. But it is not working and I would like to know why. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: bug with SSLVerifyClient?
On 2016-11-21 12:40, Helmut K. C. Tessarek wrote: > Can someone please shed some light on this? Anyone? I really hoped that somebody who knew the code could explain this behavior to me, since it makes no sense (and contradicts the documentation). Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
bug with SSLVerifyClient?
Hello, According to the documentation SSLVerifyClient can be used in a directory context. But I noticed that it is completely ignored (it always asks for a user/password, no matter, if I have the client cert installed or not). Here are the config directives (ignore the external provider): Options Indexes FollowSymLinks SSLVerifyClient optional SSLVerifyDepth 2 AuthType Basic AuthName "Restricted Section server" AuthBasicProvider ibmdb2 AuthIBMDB2User user AuthIBMDB2Password password AuthIBMDB2Database dbname AuthIBMDB2UserProc mod_authnz.getpassword AuthIBMDB2GroupProc mod_authnz.getgroups Include /etc/httpd/extra/file_with_require_expr.conf Require user my_user Please note that it works perfectly, if I create a virtual host and move the following out of the directory section and put it in the virtual host context: SSLVerifyClient optional SSLVerifyDepth 2 So either I am mnissing something, or the documention is wrong, or there's a bug somewhere. Can someone please shed some light on this? Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://sks.pkqs.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: connection ids
On 2016-09-28 11:16, Stefan Eissing wrote: > Any advice on how to convert the master connection id into a unique > slave connection id with high probability? How about using a UUID? Either v4 or a somewhat derived version of it: --4xxx-yxxx- e.g. use the first part () to indicate the master connection. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://sks.pkqs.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: apr_shm_create succeeds then fails on Mac OS X
On 27.12.15 8:47 , Sorin Manolache wrote: > I think that the location of the shmfile must be on a filesystem of a special > type, namely tmpfs, which maps in memory and not on disk. Execute "mount" and > check if you have such filesystems mounted. For example on my Linux machine: In that case the module wouldn't work on Linux either, since the '/tmp/...' path is hard-coded and /tmp is usually not a tmpfs. Just my 2 cents. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://sks.pkqs.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: documentation issues for mod_authn_socache
On 2015-06-17 18:03, Helmut K. C. Tessarek wrote: Hello, http://httpd.apache.org/docs/2.4/mod/mod_authn_socache.html There are 2 things I want to mention: 1) cacheing is not a word. It should be replaced with caching on the entire page 2) AuthnCacheSOCache Directive: If not set, your platform's default will be used. There's no indication whatsoever what the platforms' defaults actually are. Can someone please tell me what the platforms' defaults are? I'm mostly interested in Linux and MacOSX, but a list would be nice in the docs. Does anyone have any input on this? Or is this the wrong list for doc issues? -- regards Helmut K. C. Tessarek lookup http://sks.pkqs.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: documentation issues for mod_authn_socache
On 2015-06-22 16:29, Nick Kew wrote: We don't know the platforms' defaults. They're up to the packagers, and those sysops who make an active decision. I don't understand. What do you mean by this is up to the packagers? Is there a config option that decides this? If yes, let me ask this: what, if nothing is set? Then there is no caching? What is used when someone calls the API ap_authn_cache_store? I'm sorry, but this makes no sense. The defaults are in the code, aren't they? There should be something in the code like: If on Linux and AuthnCacheSOCache not set, then use . A default value is not something that is normaly chosen, and if it is, it should be at least explained how. What about my 1st item? Misspelling of caching? How to fix it, who can fix it? Can I clone a repo and create a pull request or do I have do work with svn? -- regards Helmut K. C. Tessarek lookup http://sks.pkqs.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
ap_authn_cache_store call for groups
I was looking into caching of user credentials, but I think I might be missing something. The call ap_authn_cache_store seems to store user credentials which will help, if you have a directive like 'Require valid-user', but it won't help for directives like 'Require group admin'. Am I right? So in case of an authentication module that uses database queries, all subsequent requests will still generate SQL statements for the user/group matching. Which means that only half of the database requests are actually cached. Can someone please elaborate. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://sks.pkqs.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
documentation issues for mod_authn_socache
Hello, http://httpd.apache.org/docs/2.4/mod/mod_authn_socache.html There are 2 things I want to mention: 1) cacheing is not a word. It should be replaced with caching on the entire page 2) AuthnCacheSOCache Directive: If not set, your platform's default will be used. There's no indication whatsoever what the platforms' defaults actually are. Can someone please tell me what the platforms' defaults are? I'm mostly interested in Linux and MacOSX, but a list would be nice in the docs. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://sks.pkqs.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: ap_authn_cache_store call for groups
On 17.06.15 18:56 , Eric Covener wrote: Sounds right. The authn in the name is shorthand for authentication (vs authorization). It seems possible to shoehorn other data into this cache though, but it's not clear to me what it adds using socache directly. The problem is that I don't know how. I just read the information in the documentation http://webauth.stanford.edu/manual/mod/mod_authn_socache.html how to use it to cache credentials. I wrote my own caching algorithms for my module, but learned that Apache provides this funtionality already. Or at least part of it - as in user caching. That's why I thought of getting rid of my own caching (which caches users and group info) and make use of already available functionality. Why reinvent the wheel? I just can't figure out how to cache group info. My module is an authnz module, but I couldn't find an authz_socache variant. Is there something like that? Are there any examples? Maybe this is off topic here, but I'd appreciate any pointers. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://sks.pkqs.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: [Patch] Simplifying mod_alias
On 21.12.14 9:41 , Graham Leggett wrote: What we should do in future is remove all the *Match directives and move them into a mod_alias_compat module, leaving just Alias/Redirect/ScriptAlias in mod_alias, same as we did with authnz in httpd v2.4. +1. In SW development a lot of people mixup the type of break: configurational, behavioral, and functional. One does not necessarily have to imply the other(s). In any case, this need for backwards compatibilty kills innovation and advancement. I won't go into details, since it may sound like ranting. What I want to say though is that Apache's compat modules are a great solution and I hoped more projects would use this approach. -- regards Helmut K. C. Tessarek lookup http://sks.pkqs.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
