On 2023/05/04 08:34:32 Ruediger Pluem wrote:
> This is a formal vote on whether we should move our read/write repository
> from Subversion to Git.
> This means that our latest read/write repository will be no longer available
> via svn.apache.org. It
> will be available via Git at
>
On 2022/07/29 06:19:03 Ruediger Pluem wrote:
>
>
> On 7/16/22 10:28 AM, Ivan Zhakov wrote:
> > On Wed, 13 Jul 2022 at 18:06, Yann Ylavic > <mailto:ylavic@gmail.com>> wrote:
> >
> > On Wed, Jul 13, 2022 at 1:38 PM Ivan Zh
On Wed, 13 Jul 2022 at 18:06, Yann Ylavic wrote:
> On Wed, Jul 13, 2022 at 1:38 PM Ivan Zhakov wrote:
> >
> > On Sun, 10 Jul 2022 at 19:52, Yann Ylavic wrote:
> > >
> > > Let me explain (maybe), I thought that PCRE2's match_data were not
> > > only c
On Sun, 10 Jul 2022 at 19:52, Yann Ylavic wrote:
>
> On Fri, Jul 8, 2022 at 7:15 PM Ivan Zhakov wrote:
> >
> > On Fri, 8 Jul 2022 at 19:58, Yann Ylavic wrote:
> > >
> > > The main downside is:
> > >
> > > > +#ifndef AP_PCRE_
On Wed, 29 Jun 2022 at 01:28, Yann Ylavic wrote:
>
> On Tue, Jun 28, 2022 at 6:08 PM Ivan Zhakov wrote:
> >
> > On Tue, 28 Jun 2022 at 00:24, Yann Ylavic wrote:
> > >
> > > Hi Ivan,
> > >
> > > On Mon, Jun 27, 2022 at 8:19 PM Ivan Zhakov
On Fri, 8 Jul 2022 at 19:15, Ivan Zhakov wrote:
>
> On Thu, 30 Jun 2022 at 20:14, Ivan Zhakov wrote:
> >
> > > > > I think that we could try an alternative approach for that part of
> > > > > the problem. The alternative approach would have the same
On Mon, 11 Jul 2022 at 10:17, Stefan Eissing wrote:
>
>
> > Am 10.07.2022 um 18:56 schrieb Ivan Zhakov :
> >
> > On Mon, 20 Jun 2022 at 11:24, Stefan Eissing wrote:
> > I would like to move the h2 worker pool into the mpm at some time in the
> future. To be
stion is what API would be suitable to implement for
different MPM.
Can we use something like implemented by APR threadpool:
threadpool_task_push()
threadpool_task_cancel()
threadpool_task_schedule(apr_interval_t)
?
--
Ivan Zhakov
er do I see
> what are your grievances against thread_local..
>
1. tls storage is growing to maximum captures count. So it requires
more than one or two allocations.
2. tls storage doesn't support dynamic MPM that uses native threads
3. access to tls storage requires hash lookup.
4. Windows build is currently broken due to tls storage API changes.
5. Using tls reserves the memory, even if pcre is not being used
afterwards. This can be thought as of implicitly increasing the
per-thread stack size.
6. With new code there will be no actual allocations in real-world cases.
--
Ivan Zhakov
r/util_pcre.c (original)
> +++ httpd/httpd/trunk/server/util_pcre.c Tue Jan 25 17:34:57 2022
> @@ -269,7 +269,7 @@ AP_DECLARE(int) ap_regcomp(ap_regex_t *
> * context per thread (in Thread Local Storage, TLS) grown as needed, and
> while
> * at it we do the same for PCRE1 ints vectors. Note that this requires a
> fast
> * TLS mechanism to be worth it, which is the case of
> apr_thread_data_get/set()
> - * from/to apr_thread_current() when APR_HAS_THREAD_LOCAL; otherwise we'll do
> + * from/to ap_thread_current() when AP_HAS_THREAD_LOCAL; otherwise we'll do
> * the allocation and freeing for each ap_regexec().
> */
>
> @@ -318,7 +318,7 @@ void free_match_data(match_data_pt data,
> #endif
> }
>
> -#if APR_HAS_THREAD_LOCAL
> +#if AP_HAS_THREAD_LOCAL
>
> struct apreg_tls {
> match_data_pt data;
> @@ -342,10 +342,10 @@ static match_data_pt get_match_data(apr_
> apr_thread_t *current;
> struct apreg_tls *tls = NULL;
>
> -/* Even though APR_HAS_THREAD_LOCAL, we may still be called by a
> +/* Even though AP_HAS_THREAD_LOCAL, we may still be called by a
> * native/non-apr thread, let's fall back to alloc/free in this case.
> */
> -current = apr_thread_current();
> +current = ap_thread_current();
> if (!current) {
> *to_free = 1;
> return alloc_match_data(size, ovector, small_vector);
> @@ -391,7 +391,7 @@ static match_data_pt get_match_data(apr_
> return tls->data;
> }
>
> -#else /* !APR_HAS_THREAD_LOCAL */
> +#else /* !AP_HAS_THREAD_LOCAL */
>
> static APR_INLINE match_data_pt get_match_data(apr_size_t size,
> match_vector_pt *ovector,
> @@ -402,7 +402,7 @@ static APR_INLINE match_data_pt get_matc
> return alloc_match_data(size, ovector, small_vector);
> }
>
> -#endif /* !APR_HAS_THREAD_LOCAL */
> +#endif /* !AP_HAS_THREAD_LOCAL */
>
> AP_DECLARE(int) ap_regexec(const ap_regex_t *preg, const char *string,
> apr_size_t nmatch, ap_regmatch_t *pmatch,
>
>
--
Ivan Zhakov
On Thu, 30 Jun 2022 at 20:14, Ivan Zhakov wrote:
>
> > > > I think that we could try an alternative approach for that part of the
> > > > problem. The alternative approach would have the same characteristics
> > > > as the approach that had been used for
cate for the number of
captures in the regular expression (preg->re_nsub). An additional
improvement would be to cap the allocation size based on the passed-in
limit (nmatch). I'll try to handle that separately.
Thoughts?
--
Ivan Zhakov
Index: server/util_pcre.c
=
On Tue, 28 Jun 2022 at 00:24, Yann Ylavic wrote:
>
> Hi Ivan,
>
> On Mon, Jun 27, 2022 at 8:19 PM Ivan Zhakov wrote:
> >
> > For the longer version, let me first outline a few problems with the
> > current apr_thread_current() API:
> >
> > 1) ap
) a try.
Thoughts?
--
Ivan Zhakov
Yes, I see now. But it will be an incorrect value in case of a string
larger than INT_MAX. Not a big issue, but IMHO strings larger than
INT_MAX also are not big issue.
On Wed, 8 Jun 2022 at 18:26, Eric Covener wrote:
>
> On Wed, Jun 8, 2022 at 11:10 AM Ivan Zhakov wrote:
> >
>
{
> +int rc;
> +
> +rc = ap_rwrite(str, INT_MAX, r);
> +if (rc < 0) {
> +return rc;
> +}
> +else {
> +str += INT_MAX;
> + len -= INT_MAX;
> +}
> +}
> +}
After this change apr_rputs() doesn't return value.
--
Ivan Zhakov
were the one to ask, I would say that r1889793 is too large
to be released in a patch release, and should instead be included in
2.6.x.
--
Ivan Zhakov
s.
Unfortunately, I don't have time right now to investigate this issue
further, but I think it's a critical regression for the patch release.
[1] https://tools.ietf.org/html/rfc7232#section-4.1
--
Ivan Zhakov
able_unset(r->headers_out, "Content_Length");
> + apr_table_unset(r->headers_out, "Content_MD5");
> + apr_table_unset(r->headers_out, "Content_Range");
> + apr_table_unset(r->headers_out, "ETag");
> + apr_table_unset(r->headers_out, "TE");
> + apr_table_unset(r->headers_out, "Trailer");
> + apr_table_unset(r->headers_out, "Transfer_Encoding");
>
Maybe I am missing some context, but header names use dash, not
underscore. I.e Content-Encoding, not Content_Encoding.
--
Ivan Zhakov
On Tue, 27 Aug 2019 at 19:04, Roy T. Fielding wrote:
>
> > On Aug 27, 2019, at 5:19 AM, Ivan Zhakov wrote:
> >
> > On Wed, 14 Mar 2018 at 10:05, Ivan Zhakov wrote:
> >>
> >> Hi,
> >>
> >> Please find patch that changes HTTPD to return HTT
On Wed, 14 Mar 2018 at 10:05, Ivan Zhakov wrote:
>
> Hi,
>
> Please find patch that changes HTTPD to return HTTP 431 (Request
> Header Fields Too Large) for requests with large headers. This status
> code is defined by RFC 6585 [1]. Currently HTTPD returns generic HTTP
> 400
On Sat, 13 Oct 2018 at 23:37, William A Rowe Jr wrote:
>
> On Sat, Oct 13, 2018 at 2:06 PM Ivan Zhakov wrote:
>>
>> On Sat, 13 Oct 2018 at 20:00, Gregg Smith wrote:
>>>
>>> On 10/13/2018 8:32 AM, William A Rowe Jr wrote:
>>> > Sorry, I don't
ilding
mod_ssl with OpenSSL compiled with option --no-stdio.
--
Ivan Zhakov
://tools.ietf.org/html/rfc6585#section-5
--
Ivan Zhakov
Index: include/httpd.h
===
--- include/httpd.h (revision 1801146)
+++ include/httpd.h (working copy)
@@ -567,6 +567,7 @@
((x
EP)"
> +ALL : "gen_test_char - Win32 Debug" "libaprutil - Win32 Debug" "libapriconv
> - Win32 Debug" "libapr - Win32 Debug" ".\server\test_char.h"
> ".\include\mod_watchdog.h" ".\include\mod_so.h" ".\include\mod
Please find attached patch that removes unused values of io_state_e
enum in mpm_winnt.
--
Ivan Zhakov
Index: server/mpm/winnt/child.c
===
--- server/mpm/winnt/child.c(revision 1801088)
+++ server/mpm/winnt/child.c(working
committer, but I'm Subversion committer so
I'm familiar with httpd code.
--
Ivan Zhakov
.
--
Ivan Zhakov
abstraction that is responsible for
I/O and waiting for completion.
[1]
http://www.ulduzsoft.com/2014/01/practical-difference-between-epoll-and-windows-io-completion-ports-iocp/
--
Ivan Zhakov
and
child could not have required permissions if compiled on Windows Vista
[1]. It' better to request only required SYNCHRONIZE permission.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
find Windows _source_ package for Apache 2.2.12. I mean zip
archive like this
http://www.apache.org/dist/httpd/httpd-2.2.11-win32-src-r2.zip.
Is Windows source package also unofficial?
--
Ivan Zhakov
VisualSVN Team
On Fri, Jul 31, 2009 at 11:11 AM, William A. Rowe,
Jr.wr...@rowe-clan.net wrote:
Ivan Zhakov wrote:
I cannot find Windows _source_ package for Apache 2.2.12. I mean zip
archive like this
http://www.apache.org/dist/httpd/httpd-2.2.11-win32-src-r2.zip.
Is Windows source package also unofficial
=90571
--
Ivan Zhakov
VisualSVN Team
--- server\config.c.orig 2008-12-02 16:28:22.0 +0300
+++ server\config.c 2009-06-21 23:35:24.41200 +0400
@@ -1351,8 +1351,8 @@
{
char *newpath = NULL;
apr_status_t rv;
-rv = apr_filepath_merge(newpath, ap_server_root, file
On 10/13/05, Bill Stoddard [EMAIL PROTECTED] wrote:
Ivan Zhakov wrote:
Hi!We have Apache/Subversion server under Windows Server 2003. And I
wascome into problem with restarting server that process long request(more
than 180 seconds). It's usual for bug Subversion repository. Isee messages
worker threads. Why is it? Why
mpm_winnt behavior incompatible to perfork behavior which waits
infinityle for stopping child processes? It causes really problems on
maintance and also doesn't permit use MaxRequestsPerChild option.
PS: Sorry if it is not right place for such questions.
--
Ivan Zhakov
35 matches
Mail list logo
