Re: Time To Propose Your ApacheCon 2019 Project Summit
No, nobody has done. On Wed, Nov 28, 2018, 07:54 Daniel Ruggeri We've traditionally had a day or two of content for httpd... has anyone > added an item to the form? I cannot see the backing database/spreadsheet in > the apachecon gsuite location... > > If not, I can propose and coordinate the track... hopefully with others > (Daniel?, Bill?) who are also on planners@, providing backup as I become > busy at the start of the semester. > -- > Daniel Ruggeri > > On November 27, 2018 8:30:51 AM CST, Rich Bowen wrote: >> >> Save the date: ApacheCon North America will be held in Las Vegas, at the >> Flamingo Hotel, September 9th through 12th, 2019. This is our 20th >> anniversary event, and we really want you, your project, and its >> community, to be involved. >> >> If you want to be part of making this event happen, please join the >> privately-archived planners@ mailing list by sending email to >> planners-subscr...@apachecon.com from your apache.org email address. >> >> A call for presentations will be announced soon. You should start giving >> some thought to what story your project wants to tell at this event, and >> working with your project community to craft presentations around that >> story. >> >> We will have a number of spaces for projects to conduct project summits, >> hackathons, or mini-conferences, lasting anywhere from a half day to the >> entire four days of the event. >> >> If your project, or group of several related projects, would like to >> claim an entire track (one, two, or three days of content) and craft >> that story yourselves, please propose your track or summit here: >> https://goo.gl/forms/lczPlXTmGNIsRf823 >> >> The deadline for proposing a project/topic event is January 7th, (The >> first Monday of the new year) so that we can reflect these topics in the >> CFP. >> >> If your project holds your own standalone events(s) please consider >> co-locating with ApacheCon this coming year. We’ll help you promote your >> event, both as part of ApacheCon, and as its own brand. You get the best >> of both worlds - you get your own event, with control of your content, >> and you get to be part of a larger convention with a broader audience. >> >> This is your conference, and we are counting on you to step up and make >> it yours. >> >> Stay tuned for more information, on the planners list, and on our >> Twitter account @apachecon. And we look forward to seeing you to see you >> in Vegas in September! >> >> Rich Bowen, VP Conferences, and the ApacheCon Planners >> >>
Re: svn commit: r1853407 - in /httpd/httpd/trunk/modules: http2/mod_proxy_http2.c proxy/mod_proxy_http.c
Ok, took the opportunity to add that to my pytest suite in mod-h2.
You need a local "pytest", "curl" and "nghttp" executable. If you checkout
https://github.com/icing/mod_h2 master, run the configure:
> autoreconf -i
> automake
> autoconf
> ./configure --with-apxs=/opt/apache-2.4.x/bin/apxs --enable-werror
> make
> make test
("/opt/apache-2.4.x" is where I install my locally build 2.4.x branch. Adjust
to your needs.)
You should see, on an unpatched 2.4.x
=
test session starts platform darwin -- Python 2.7.10, pytest-3.0.7, py-1.4.33,
pluggy-0.4.0
rootdir: /Users/sei/projects/mod-h2/test/e2e, inifile:
collected 86 items
test_001_httpd_alive.py ..
test_002_curl_basics.py ..
test_003_get.py .
test_004_post.py
test_100_conn_reuse.py .
test_101_ssl_reneg.py ...
test_102_require.py ..
test_103_upgrade.py ...
test_200_header_invalid.py ...
test_201_header_conditional.py ..
test_202_trailer.py
test_300_interim.py ...
test_400_push.py ...
test_401_early_hints.py ..
test_500_proxy.py ...
= 86 passed
in 23.13 seconds
On a 2.4.x installed with the proposed proxy patches, the test_500_24 fails
with a 400 response code from the server.
You can just run that test case via
> (cd test/e2e && pytest -k 500_24)
Hope this helps.
-Stefan
> Am 12.02.2019 um 13:59 schrieb Yann Ylavic :
>
> OK, thanks Stefan, will look at it.
>
>
> On Tue, Feb 12, 2019 at 11:12 AM ste...@eissing.org
> wrote:
>>
>> Yann,
>>
>> this works fine in my tests on trunk. However on 2.4.x I get often errors
>> when uploading data without content-length.
>>
>> Scenario from the h2 test suite, HTTP/2 on the front, old skool HTTP/1.1
>> proxy to itself:
>>
>>> while true; do nghttp -v --expect-continue --data=gen/tmp/updata
>>> -H'Content-Type: multipart/form-data; boundary=DSAJKcd9876'
>>> --no-content-length http://test.example.org:12345/proxy/upload.py; done |
>>> fgrep 400
>>
>> [ 0.009] recv (stream_id=13) :status: 400
>> 400 Bad Request
>> [ 0.007] recv (stream_id=13) :status: 400
>> 400 Bad Request
>> ...
>>
>>
>> /etc/hosts
>>
>> 127.0.0.1 test.example.orgtest
>>
>> httpd config:
>>
>>ProxyPass "/proxy" "balancer://http-local"
>>ProxyPassReverse "/proxy" "balancer://http-local"
>>
>>
>>BalancerMember "http://127.0.0.1:12345; hcmethod=GET hcuri=/ ttl=4
>>
>>
>>
>>> cat gen/tmp/updata
>> --DSAJKcd9876
>> Content-Disposition: form-data; name="xxx"; filename="x"
>> Content-Type: text/plain
>>
>> testing mod_h2
>> --DSAJKcd9876
>> Content-Disposition: form-data; name="file"; filename="data-1k"
>> Content-Type: application/octet-stream
>> Content-Transfer-Encoding: binary
>>
>> 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
>> 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
>> 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
>> 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
>> 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
>> 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
>> 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
>> 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
>> 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
>> 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
>>
>> --DSAJKcd9876--
>>
>>
>>
>>> Am 11.02.2019 um 22:55 schrieb yla...@apache.org:
>>>
>>> Author: ylavic
>>> Date: Mon Feb 11 21:55:43 2019
>>> New Revision: 1853407
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1853407=rev
>>> Log:
>>> mod_proxy_http: rework the flushing strategy when forwarding the request
>>> body.
>>>
>>> Since the forwarding of 100-continue (end to end) in r1836588, we depended
>>> on
>>> reading all of the requested HUGE_STRING_LEN bytes to avoid the flushes, but
>>> this is a bit fragile.
>>>
>>> This commit introduces the new stream_reqbody_read() function which will
>>> try a
>>> nonblocking read first and, if it fails with EAGAIN, will flush on the
>>> backend
>>> side before blocking for the next client side read.
>>>
>>> We can then use it in stream_reqbody_{chunked,cl}() to flush client
>>> forwarded
>>> data only when necessary. This both allows "optimal" flushing and simplifies
>>> code (note that spool_reqbody_cl() also makes use of the new function but
>>> not
>>> its nonblocking/flush functionality, thus only for consistency with the two
>>>
Re: svn commit: r1853407 - in /httpd/httpd/trunk/modules: http2/mod_proxy_http2.c proxy/mod_proxy_http.c
OK, thanks Stefan, will look at it.
On Tue, Feb 12, 2019 at 11:12 AM ste...@eissing.org wrote:
>
> Yann,
>
> this works fine in my tests on trunk. However on 2.4.x I get often errors
> when uploading data without content-length.
>
> Scenario from the h2 test suite, HTTP/2 on the front, old skool HTTP/1.1
> proxy to itself:
>
> > while true; do nghttp -v --expect-continue --data=gen/tmp/updata
> > -H'Content-Type: multipart/form-data; boundary=DSAJKcd9876'
> > --no-content-length http://test.example.org:12345/proxy/upload.py; done |
> > fgrep 400
>
> [ 0.009] recv (stream_id=13) :status: 400
> 400 Bad Request
> [ 0.007] recv (stream_id=13) :status: 400
> 400 Bad Request
> ...
>
>
> /etc/hosts
>
> 127.0.0.1 test.example.orgtest
>
> httpd config:
>
> ProxyPass "/proxy" "balancer://http-local"
> ProxyPassReverse "/proxy" "balancer://http-local"
>
>
> BalancerMember "http://127.0.0.1:12345; hcmethod=GET hcuri=/ ttl=4
>
>
>
> > cat gen/tmp/updata
> --DSAJKcd9876
> Content-Disposition: form-data; name="xxx"; filename="x"
> Content-Type: text/plain
>
> testing mod_h2
> --DSAJKcd9876
> Content-Disposition: form-data; name="file"; filename="data-1k"
> Content-Type: application/octet-stream
> Content-Transfer-Encoding: binary
>
> 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
> 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
> 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
> 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
> 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
> 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
> 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
> 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
> 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
> 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
>
> --DSAJKcd9876--
>
>
>
> > Am 11.02.2019 um 22:55 schrieb yla...@apache.org:
> >
> > Author: ylavic
> > Date: Mon Feb 11 21:55:43 2019
> > New Revision: 1853407
> >
> > URL: http://svn.apache.org/viewvc?rev=1853407=rev
> > Log:
> > mod_proxy_http: rework the flushing strategy when forwarding the request
> > body.
> >
> > Since the forwarding of 100-continue (end to end) in r1836588, we depended
> > on
> > reading all of the requested HUGE_STRING_LEN bytes to avoid the flushes, but
> > this is a bit fragile.
> >
> > This commit introduces the new stream_reqbody_read() function which will
> > try a
> > nonblocking read first and, if it fails with EAGAIN, will flush on the
> > backend
> > side before blocking for the next client side read.
> >
> > We can then use it in stream_reqbody_{chunked,cl}() to flush client
> > forwarded
> > data only when necessary. This both allows "optimal" flushing and simplifies
> > code (note that spool_reqbody_cl() also makes use of the new function but
> > not
> > its nonblocking/flush functionality, thus only for consistency with the two
> > others, simplification and common error handling).
> >
> > Also, since proxy_http_req_t::flushall/subprocess_env::proxy-flushall are
> > now
> > meaningless (and unused) on the backend side, they are renamed respectively
> > to
> > prefetch_nonblocking/proxy-prefetch-nonblocking, and solely determine
> > whether
> > to prefetch in nonblocking mode or not. These flags were trunk only and may
> > not be really useful if we decided to prefetch in nonblocking mode in any
> > case,
> > but for 2.4.x the opt-in looks wise.
> >
> > Modified:
> >httpd/httpd/trunk/modules/http2/mod_proxy_http2.c
> >httpd/httpd/trunk/modules/proxy/mod_proxy_http.c
> >
> > Modified: httpd/httpd/trunk/modules/http2/mod_proxy_http2.c
> > URL:
> > http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/mod_proxy_http2.c?rev=1853407=1853406=1853407=diff
> > ==
> > --- httpd/httpd/trunk/modules/http2/mod_proxy_http2.c (original)
> > +++ httpd/httpd/trunk/modules/http2/mod_proxy_http2.c Mon Feb 11 21:55:43
> > 2019
> > @@ -77,7 +77,6 @@ typedef struct h2_proxy_ctx {
> >
> > unsigned standalone : 1;
> > unsigned is_ssl : 1;
> > -unsigned flushall : 1;
> >
> > apr_status_t r_status; /* status of our first request work */
> > h2_proxy_session *session; /* current http2 session against backend */
> > @@ -509,7 +508,6 @@ static int proxy_http2_handler(request_r
> > ctx->is_ssl = is_ssl;
> > ctx->worker = worker;
> > ctx->conf = conf;
> > -ctx->flushall
Re: svn commit: r1853407 - in /httpd/httpd/trunk/modules: http2/mod_proxy_http2.c proxy/mod_proxy_http.c
Yann,
this works fine in my tests on trunk. However on 2.4.x I get often errors when
uploading data without content-length.
Scenario from the h2 test suite, HTTP/2 on the front, old skool HTTP/1.1 proxy
to itself:
> while true; do nghttp -v --expect-continue --data=gen/tmp/updata
> -H'Content-Type: multipart/form-data; boundary=DSAJKcd9876'
> --no-content-length http://test.example.org:12345/proxy/upload.py; done |
> fgrep 400
[ 0.009] recv (stream_id=13) :status: 400
400 Bad Request
[ 0.007] recv (stream_id=13) :status: 400
400 Bad Request
...
/etc/hosts
127.0.0.1 test.example.orgtest
httpd config:
ProxyPass "/proxy" "balancer://http-local"
ProxyPassReverse "/proxy" "balancer://http-local"
BalancerMember "http://127.0.0.1:12345; hcmethod=GET hcuri=/ ttl=4
> cat gen/tmp/updata
--DSAJKcd9876
Content-Disposition: form-data; name="xxx"; filename="x"
Content-Type: text/plain
testing mod_h2
--DSAJKcd9876
Content-Disposition: form-data; name="file"; filename="data-1k"
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
--DSAJKcd9876--
#!/usr/bin/env python
import cgi, os
import cgitb; cgitb.enable()
status = '200 Ok'
def mk_body(s):
return ("\n%s\n" % (s))
try: # Windows needs stdio set for binary mode.
import msvcrt
msvcrt.setmode (0, os.O_BINARY) # stdin = 0
msvcrt.setmode (1, os.O_BINARY) # stdout = 1
except ImportError:
pass
form = cgi.FieldStorage()
body=''
# Test if the file was uploaded
if 'file' in form:
# A nested FieldStorage instance holds the file
fileitem = form['file']
# strip leading path from file name to avoid directory traversal attacks
fn = os.path.basename(fileitem.filename)
f = open('./files/' + fn, 'wb');
f.write(fileitem.file.read())
f.close()
body = mk_body('The file "%s" was uploaded successfully' %fn)
elif 'remove' in form:
remove = form['remove'].value
try:
fn = os.path.basename(remove)
os.remove('./files/' + fn)
message = 'The file "' + fn + '" was removed successfully'
except OSError, e:
message = 'Error removing ' + fn + ': ' + e.strerror
status = '404 File Not Found'
else:
body = mk_body('''Upload File
Upload''')
print "Status: %s" % (status)
print "Content-Type: text/html"
print "Content-Length: %d" % (len(body) + 1)
print ""
print "%s" % (body)
> Am 11.02.2019 um 22:55 schrieb yla...@apache.org:
>
> Author: ylavic
> Date: Mon Feb 11 21:55:43 2019
> New Revision: 1853407
>
> URL: http://svn.apache.org/viewvc?rev=1853407=rev
> Log:
> mod_proxy_http: rework the flushing strategy when forwarding the request body.
>
> Since the forwarding of 100-continue (end to end) in r1836588, we depended on
> reading all of the requested HUGE_STRING_LEN bytes to avoid the flushes, but
> this is a bit fragile.
>
> This commit introduces the new stream_reqbody_read() function which will try a
> nonblocking read first and, if it fails with EAGAIN, will flush on the backend
> side before blocking for the next client side read.
>
> We can then use it in stream_reqbody_{chunked,cl}() to flush client forwarded
> data only when necessary. This both allows "optimal" flushing and simplifies
> code (note that spool_reqbody_cl() also makes use of the new function but not
> its nonblocking/flush functionality, thus only for consistency with the two
> others, simplification and common error handling).
>
> Also, since proxy_http_req_t::flushall/subprocess_env::proxy-flushall are now
> meaningless (and unused) on the backend side, they are renamed respectively to
> prefetch_nonblocking/proxy-prefetch-nonblocking, and solely determine whether
> to prefetch in nonblocking mode or not. These flags were trunk only and may
> not be really useful if we decided to prefetch in nonblocking mode in any
> case,
> but for 2.4.x the opt-in looks wise.
>
> Modified:
>httpd/httpd/trunk/modules/http2/mod_proxy_http2.c
>
