Systems, Inc.
/Orion - The Enterprise Jamstack Wiki/
/
/
*From:* Raymond Field via dev
*Sent:* Tuesday, July 4, 2023 7:36:33 AM
*To:* dev@httpd.apache.org
*Subject:* libapreq 2.17 POST upload with empty filename parameter
Hi
2.17 was a dud security release. Use trunk
Joe Schaefer, Ph.D
+1 (954) 253-3732
SunStar Systems, Inc.
Orion - The Enterprise Jamstack Wiki
From: Raymond Field via dev
Sent: Tuesday, July 4, 2023 7:36:33 AM
To: dev@httpd.apache.org
Subject: libapreq 2.17 POST
Hi,
I don't know if this is the correct place to report an issue with
libapreq2, please let me know where I should sent this report if this
isn't the correct place.
If I POST a form to the server that contains unfilled file upload fields, the
library seems to give up processing at
Hu? Halloween?
> Anfang der weitergeleiteten Nachricht:
>
> Von: announce-h...@httpd.apache.org
> Betreff: Returned post for annou...@httpd.apache.org
> Datum: 1. November 2021 um 00:16:48 MEZ
> An: ic...@apache.org
>
>
> Hi! This is the ezmlm progra
Hi experts:
I am developing a http mod_example for my web application. I want to proecess html form with POST
enctype="multipart/form-data", for uploading files to my server. I google searched, did
not find any API for POST "multipart/form-data" processing, like ap
ch bz62186_httpd_bugfix.patch). So far the
tests I've done are successful, i.e. the request is now correctly logged
as POST request.
I've filed this issue some days ago as
https://bz.apache.org/bugzilla/show_bug.cgi?id=62186 , but so far it
didn't get any comments yet. Could anybody please take a look?
Kind regards,
Micha
ng a backup of the original
request's method and restoring it as soon as ap_internal_redirect()
returns (see attached patch bz62186_httpd_bugfix.patch). So far the
tests I've done are successful, i.e. the request is now correctly logged
as POST request.
I've filed this issue some days ag
> On Jan 3, 2017, at 8:04 PM, Noel Butler wrote:
>
> On 03/01/2017 23:11, Jim Jagielski wrote:
>
>> Back in the "old days" we used to provide complimentary builds
>> for some OSs... I'm not saying we go back and do that necessarily,
>> but maybe also providing easily consumable other formats wh
On Tue, Jan 3, 2017 at 7:04 PM, Noel Butler wrote:
>
> On 03/01/2017 23:11, Jim Jagielski wrote:
>
> Back in the "old days" we used to provide complimentary builds
> for some OSs... I'm not saying we go back and do that necessarily,
> but maybe also providing easily consumable other formats when w
On 03/01/2017 23:11, Jim Jagielski wrote:
> Back in the "old days" we used to provide complimentary builds
> for some OSs... I'm not saying we go back and do that necessarily,
> but maybe also providing easily consumable other formats when we
> do a release, as a "service" to the community might m
On Jan 3, 2017 07:11, "Jim Jagielski" wrote:
Back in the "old days" we used to provide complimentary builds
for some OSs... I'm not saying we go back and do that necessarily,
but maybe also providing easily consumable other formats when we
do a release, as a "service" to the community might make
Back in the "old days" we used to provide complimentary builds
for some OSs... I'm not saying we go back and do that necessarily,
but maybe also providing easily consumable other formats when we
do a release, as a "service" to the community might make a lot
of sense.
On 31 Dec 2016, at 00:09, Stefan Fritsch wrote:
> * the longer 2.6/3.0 takes the more half-baked/half-finished stuff
> accumulates
> that needs to be fixed before a release.
>
> But I don't have any ideas how to resolve this.
Did you see my "A new release process?" thread? :)
On Saturday, 24 December 2016 08:29:35 CET Rich Bowen wrote:
> From my perspective, watching Nginx gain traction through superior
> marketing, and channeling Dilbert's Pointy Haired Boss in assuming that
> everything which I have never done must be simple, I, for one, would
> like to see us release
osting support from the
httpd project?
Rick Houser
Web Administration
> -Original Message-
> From: Daniel Ruggeri [mailto:drugg...@primary.net]
> Sent: Friday, December 30, 2016 10:12
> To: dev@httpd.apache.org
> Subject: Re: The Version Bump fallacy [Was Re: Post 2.4.25]
On 12/28/2016 6:40 PM, Yehuda Katz wrote:
> On Wed, Dec 28, 2016 at 12:35 AM, William A Rowe Jr
> mailto:wr...@rowe-clan.net>> wrote:
>
> Our adoption is *broadly* based on the OS distributions
> from vendors, not from people picking up our sources.
> Yes - some integrate directly from
On Thu, Dec 29, 2016 at 8:23 AM, Jim Jagielski wrote:
>
>> On Dec 28, 2016, at 6:28 PM, William A Rowe Jr wrote:
>>
>> Because fixing r->uri is such a priority, trust that I'll be voting every
>> 2.6 candidate a -1 until it exists. I don't know why the original httpd
>> founders are so hung up
On Thu, Dec 29, 2016 at 8:25 AM, Jim Jagielski wrote:
> It wasn't the paste that was the problem, but the inability
> of other email clients to determine from your email what
> parts/sections are quoted from *previous* emails.
Yann pointed me in the right direction, I believe it is fixed now.
Th
> On Dec 28, 2016, at 7:40 PM, Yehuda Katz wrote:
>
> On Wed, Dec 28, 2016 at 12:35 AM, William A Rowe Jr
> wrote:
> Our adoption is *broadly* based on the OS distributions
> from vendors, not from people picking up our sources.
> Yes - some integrate directly from source, and others
> use a n
It wasn't the paste that was the problem, but the inability
of other email clients to determine from your email what
parts/sections are quoted from *previous* emails.
> On Dec 28, 2016, at 5:49 PM, William A Rowe Jr wrote:
>
> Hi Jim,
>
> Talk to Google and the OpenOffice Team, that was a paste
> On Dec 28, 2016, at 6:28 PM, William A Rowe Jr wrote:
>
>
> Because fixing r->uri is such a priority, trust that I'll be voting every 2.6
> candidate a -1 until it exists. I don't know why the original httpd founders
> are so hung up on version number conservation, they are cheap, but we ar
Am 29.12.2016 um 07:08 schrieb William A Rowe Jr:
(Again, it's gmail, /shrug. I can attempt to undecorate but doubt I'm
moving to a local client/mail store again. If anyone has good gmail
formatting tips for their default settings, I'd love a pointer.)
yes, setup thunderbird and gmail with IM
> Am 29.12.2016 um 01:40 schrieb Yehuda Katz :
>
> On Wed, Dec 28, 2016 at 12:35 AM, William A Rowe Jr
> wrote:
> Our adoption is *broadly* based on the OS distributions
> from vendors, not from people picking up our sources.
> Yes - some integrate directly from source, and others
> use a non-O
On Wed, Dec 28, 2016 at 6:42 PM, Yann Ylavic wrote:
> [Bill, you definitely should do something with your email client, e.g.
> using plain text only, replying to your messages breaks indentation
> level (like the number of '>' preceding/according to the initial
> message)].
>
(Again, it's gmail,
[Bill, you definitely should do something with your email client, e.g.
using plain text only, replying to your messages breaks indentation
level (like the number of '>' preceding/according to the initial
message)].
On Thu, Dec 29, 2016 at 12:28 AM, William A Rowe Jr wrote:
>
> On Dec 24, 2016 07:
On Wed, Dec 28, 2016 at 12:35 AM, William A Rowe Jr
wrote:
> Our adoption is *broadly* based on the OS distributions
> from vendors, not from people picking up our sources.
> Yes - some integrate directly from source, and others
> use a non-OS distribution.
>
I think a significant number of user
On Dec 24, 2016 08:32, "Eric Covener" wrote:
> I'm not saying we don't do one so we can do the other; I'm
> saying we do both, at the same time, in parallel. I still
> don't understand why that concept is such an anathema to some
> people.
I also worry about our ability to deliver a 3.0 with eno
using on low-hanging fruit
which would make lives happier and better for our end-users.
As I said, my fear is that we will not be able to "control"
ourselves in limiting what is in 2.6, which will push the
actual release far past the point where it is even relevant.
Well as breaking c
On Dec 28, 2016 10:34, "William A Rowe Jr" wrote:
Specific
Revision
Of all Most
Recent
Of m.m Of all
Apache/1.3.x 391898 3.33% 1.3.42 42392 10.82% 0.36%
Apache/2.0.x 551117 4.68% 2.0.64 36944 6.70% 0.31%
Apache/2.2.x 7129391 60.49% 2.2.31 1332448 18.78% 11.31%
Apache/2.4.x 3713364 31.51% 2.4.17+
Hi Jim,
Talk to Google and the OpenOffice Team, that was a paste from OpenOffice
Calc.
I'll be happy to start summarizing as a shared Google sheet.
Cheers,
Bill
On Dec 28, 2016 14:22, "Jim Jagielski" wrote:
> Bill, I don't know if it's just my Email client or not (doesn't
> look like it) bu
Bill, I don't know if it's just my Email client or not (doesn't
look like it) but could you fix your Email client? It's impossible to
reply and have the quoted parts parsed out correctly. I think
it's to do w/ your messages being RTF or something.
Thx!
Included is an example of how a Reply misses
William A Rowe Jr in gmane.comp.apache.devel (Wed, 28 Dec 2016 10:46:51
-0600):
>On Wed, Dec 28, 2016 at 9:05 AM, Jan Ehrhardt wrote:
>
>> Do not underestimate the influence of control panels. On all my Centos
>> servers I am running Directadmin. DA always offers to upgrade to the
>> latest releas
7;s tear down SecuritySpace's Nov '16 dataset;
http://www.securityspace.com/s_survey/data/201611/servers.html
First off, if you follow that link, you'll find much larger numbers
associated
to those specific revisions shipped with the likes of RHEL or CentOS, Ubuntu
(particularly
On Wed, Dec 28, 2016 at 9:05 AM, Jan Ehrhardt wrote:
> William A Rowe Jr in gmane.comp.apache.devel (Tue, 27 Dec 2016 23:35:50
> -0600):
> >But the vast majority of httpd, nginx, and yes - even IIS
> >users are all running what they were handed from their
> >OS distribution.
>
> Do not underestim
cPanel too... They are moving to EA4 which is Apache 2.4.
So the idea that supplemental (ie: 2.4.x->2.4.y) patches don't
have the reach or range of larger ones (2.4.x->2.6/3.0) isn't
quite accurate.
IMO, people who are comfortable with "whatever the OS provides"
aren't the ones we are talking abo
William A Rowe Jr in gmane.comp.apache.devel (Tue, 27 Dec 2016 23:35:50
-0600):
>But the vast majority of httpd, nginx, and yes - even IIS
>users are all running what they were handed from their
>OS distribution.
Do not underestimate the influence of control panels. On all my Centos
servers I am r
On Fri, Dec 23, 2016 at 2:52 PM, Jim Jagielski wrote:
>
> As I have also stated, my personal belief is that
> 2.4 is finally reaching some traction, and if we
> "turn off" development/enhancement of 2.4, we will
> stop the uptake of 2.4 in its track.
This is where I think we have a disconnect.
> On 24 Dec 2016, at 16:32, Eric Covener wrote:
>
>> I'm not saying we don't do one so we can do the other; I'm
>> saying we do both, at the same time, in parallel. I still
>> don't understand why that concept is such an anathema to some
>> people.
>
> I also worry about our ability to deliver
> I'm not saying we don't do one so we can do the other; I'm
> saying we do both, at the same time, in parallel. I still
> don't understand why that concept is such an anathema to some
> people.
I also worry about our ability to deliver a 3.0 with enough
re-architecture for us and and function for
On Dec 24, 2016 10:57, "Jim Jagielski" wrote:
Yeah, right now the way we are "doing marketing" is by
continually adding features and enhancements to 2.4... It
is what keeps 2.4 relevant and is what either keeps current
httpd users using httpd or maybe help those on the fence decide
on httpd ins
> On Dec 24, 2016, at 8:54 AM, Eric Covener wrote:
>
> On Fri, Dec 23, 2016 at 3:28 PM, William A Rowe Jr
> wrote:
>> Next step is to actually end enhancements alltogether
>> against 2.4 (we've done that some time ago, security
>> issues notwithstanding, on 2.2), and push all of the
>> enhance
> On Dec 24, 2016, at 8:29 AM, Rich Bowen wrote:
>
>
>
> On 12/23/2016 03:52 PM, Jim Jagielski wrote:
>> Personally, I don't think that backporting stuff to
>> 2.4 prevents or disallows development on 2.6/3.0. In
>> fact, I think it helps. We can easily do both...
>> after all, we are still "w
On Fri, Dec 23, 2016 at 3:28 PM, William A Rowe Jr wrote:
> Next step is to actually end enhancements alltogether
> against 2.4 (we've done that some time ago, security
> issues notwithstanding, on 2.2), and push all of the
> enhancement effort towards 3.0 (2.5-dev). Of course,
> we should continu
On 12/23/2016 03:52 PM, Jim Jagielski wrote:
> Personally, I don't think that backporting stuff to
> 2.4 prevents or disallows development on 2.6/3.0. In
> fact, I think it helps. We can easily do both...
> after all, we are still "working" on 2.2.
>
> As I have also stated, my personal belief i
On Dec 23, 2016 9:58 PM, "Jim Jagielski" wrote:
Well, since I am actively working on trunk, I am obviously interested in
seeing continued work being done on it and the work being usable to our
users in a timely fashion. Since backports to 2.2 have not affected work on
2.4 or trunk, it is obvious
> On Dec 23, 2016, at 5:50 PM, William A Rowe Jr wrote:
>
> Just a couple quick thoughts...
>
> On Dec 23, 2016 2:55 PM, "Jim Jagielski" wrote:
>
> . We need to keep
> 2.4 viable and worthwhile
>
> So long as we fix the bugs, it is.
>
Personally, especially considering the current landscap
Well, since I am actively working on trunk, I am obviously interested in seeing
continued work being done on it and the work being usable to our users in a
timely fashion. Since backports to 2.2 have not affected work on 2.4 or trunk,
it is obvious as well that any backport efforts for 2.4 won't
Just a couple quick thoughts...
On Dec 23, 2016 2:55 PM, "Jim Jagielski" wrote:
As I have also stated, my personal belief is that
2.4 is finally reaching some traction, and if we
"turn off" development/enhancement of 2.4, we will
stop the uptake of 2.4 in its track.
I think you might be misco
Personally, I don't think that backporting stuff to
2.4 prevents or disallows development on 2.6/3.0. In
fact, I think it helps. We can easily do both...
after all, we are still "working" on 2.2.
As I have also stated, my personal belief is that
2.4 is finally reaching some traction, and if we
"tu
On Fri, Dec 23, 2016 at 2:20 PM, Jim Jagielski wrote:
> For me, it would be moving as much as we can from
> trunk to 2.4
-1. To echo your frequent use of media to emphasize
the point, with a song nearly as old as us;
https://www.youtube.com/watch?v=EsCyC1dZiN8
Next step is to actually end enha
Now that we have 2.4.25 done, I'd like us to take the
next few weeks thinking about how we'd like to see
the next release shape up.
For me, it would be moving as much as we can from
trunk to 2.4, again, to enable current users to
leverage and enjoy the goodness which is currently
"stuck" in trunk.
Hi all,
(If you're already subscribed to modules-dev@ or users@, you've already
seen this -- sorry -- but Rich Bowen suggested that I post here as well.)
I recently released a 0.1.0 version of mod_websocket, which was at one
point [1] under consideration for folding into the htt
On 22 Oct 2015, at 6:04 PM, Stefan Eissing wrote:
>> mod_ssl already worries about buffering on it’s own, there is no need to
>> recreate this functionality. Was this not working?
>
> As I wrote "it has other bucket patterns", which do not get optimized by the
> coalescing filter of mod_ssl.
On 22 Oct 2015, at 6:03 PM, Stefan Eissing wrote:
> This is all true and correct - as long as all this happens in a single
> thread. If you have multiple threads and create sub pools for each from a
> main pool, each and every create and destroy of these sub-pools, plus any
> action on the mai
On 22 Oct 2015, at 5:55 PM, Stefan Eissing wrote:
>> With the async filters this flow control is now made available to every
>> filter in the ap_filter_setaside_brigade() function. When mod_http2 handles
>> async filters you’ll get this flow control for free.
>
> No, it will not. The processin
On 22 Oct 2015, at 5:43 PM, Stefan Eissing wrote:
>> The blocking read breaks the spirit of the event MPM.
>>
>> In theory, as long as you enter the write completion state and then not
>> leave until your connection is done, this problem will go away.
>>
>> If you want to read instead of write
> Am 21.10.2015 um 16:48 schrieb Graham Leggett :
>
> On 21 Oct 2015, at 4:18 PM, Stefan Eissing
> wrote:
>
>> 7. The buckets passed down on the master connection are using another buffer
>> - when on https:// -
>> to influence the SSL record sizes on write. Another COPY is not nice, but
>>
> Am 21.10.2015 um 16:48 schrieb Graham Leggett :
>
> On 21 Oct 2015, at 4:18 PM, Stefan Eissing
> wrote:
>> 6. pool buckets are very tricky to optimize, as pool creation/destroy is not
>> thread-safe in general
>> and it depends on how the parent pools and their allocators are set up.
>> E
> Am 21.10.2015 um 16:48 schrieb Graham Leggett :
>
> On 21 Oct 2015, at 4:18 PM, Stefan Eissing
> wrote:
> [...]
>> 3. The amount of buffered bytes should be more flexible per stream and
>> redistribute a maximum for
>> the whole session depending on load.
>> 4. mod_http2 needs a process wi
(I split these up, since answers touch on different topics):
> Am 21.10.2015 um 16:48 schrieb Graham Leggett :
>
> On 21 Oct 2015, at 4:18 PM, Stefan Eissing
> wrote:
>
>> How good does this mechanism work for mod_http2? On the one side it's the
>> same, on the other quite different.
>>
>>
On 21 Oct 2015, at 4:18 PM, Stefan Eissing wrote:
> How good does this mechanism work for mod_http2? On the one side it's the
> same, on the other quite different.
>
> On the real, main connection, the master connection, where the h2 session
> resides, things are
> pretty similar with some exc
(Sorry for the long post. It was helpful for myself to write it. If this does
not
hold your interest long enough, just ignore it please.)
As I understand it - and that is incomplete - we have a usual request
processing like this:
A)
worker:
conn <--- cfilter <--- rfilter
|--b-b-b
On Sun, Nov 23, 2014 at 12:11 AM, Eric Covener wrote:
> On Thu, Nov 20, 2014 at 9:57 AM, Yann Ylavic wrote:
>> On Wed, Nov 19, 2014 at 1:13 PM, Eric Covener wrote:
>>> On Wed, Nov 19, 2014 at 4:47 AM, Yann Ylavic wrote:
Errr, this is in 2.2.x/STATUS only (not 2.4.x).
Is it already pro
On Thu, Nov 20, 2014 at 9:57 AM, Yann Ylavic wrote:
> On Wed, Nov 19, 2014 at 1:13 PM, Eric Covener wrote:
>> On Wed, Nov 19, 2014 at 4:47 AM, Yann Ylavic wrote:
>>> Errr, this is in 2.2.x/STATUS only (not 2.4.x).
>>> Is it already proposed/backported to 2.4.x (I can't find the commit)?
>>
>> I
On Wed, Nov 19, 2014 at 1:13 PM, Eric Covener wrote:
> On Wed, Nov 19, 2014 at 4:47 AM, Yann Ylavic wrote:
>> Errr, this is in 2.2.x/STATUS only (not 2.4.x).
>> Is it already proposed/backported to 2.4.x (I can't find the commit)?
>
> I diff'ed trunk and 2.4 and It seems to be absent.
>
> I don't
On Wed, Nov 19, 2014 at 4:47 AM, Yann Ylavic wrote:
> Errr, this is in 2.2.x/STATUS only (not 2.4.x).
> Is it already proposed/backported to 2.4.x (I can't find the commit)?
I diff'ed trunk and 2.4 and It seems to be absent.
I don't have the best handle on this, but if we're about to go down
int
On Wed, Nov 19, 2014 at 10:26 AM, Yann Ylavic wrote:
> Eric, Jeff, since you already voted for r1621453 in 2.4.x/STATUS
Errr, this is in 2.2.x/STATUS only (not 2.4.x).
Is it already proposed/backported to 2.4.x (I can't find the commit)?
On Sat, Aug 30, 2014 at 3:19 PM, Yann Ylavic wrote:
> On Sat, Aug 30, 2014 at 3:02 PM, Eric Covener wrote:
>> On Tue, Aug 26, 2014 at 5:22 AM, Yann Ylavic wrote:
>>> I don't think mod_reqtimeout should handle/count speculative bytes,
>>> they ought to be read for real later (and taken into accou
On Sat, Aug 30, 2014 at 3:02 PM, Eric Covener wrote:
> On Tue, Aug 26, 2014 at 5:22 AM, Yann Ylavic wrote:
>> I don't think mod_reqtimeout should handle/count speculative bytes,
>> they ought to be read for real later (and taken into account then).
>> Otherwise, the same bytes may be counted mult
On Tue, Aug 26, 2014 at 5:22 AM, Yann Ylavic wrote:
> On Mon, Aug 25, 2014 at 10:05 PM, Eric Covener wrote:
>> But it seemed a little hokey, but I didn't really understand if we
>> could instead treat that speculative read as some kind of reset point
>> and couldn't think of any other hook to tel
On Mon, Aug 25, 2014 at 4:05 PM, Eric Covener wrote:
> I am looking at this PR which I was able to recreate:
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=56729
Whoops, I got the topic backwards. Fast post, slow response.
--
Eric Covener
cove...@gmail.com
On Mon, Aug 25, 2014 at 10:05 PM, Eric Covener wrote:
> But it seemed a little hokey, but I didn't really understand if we
> could instead treat that speculative read as some kind of reset point
> and couldn't think of any other hook to tell reqtimeout to bail out.
>
> Any alternatives?
I don't t
> -Original Message-
> From: Eric Covener [mailto:cove...@gmail.com]
> Sent: Montag, 25. August 2014 22:05
> To: Apache HTTP Server Development List
> Subject: PR56729: reqtimeout bug with fast response and slow POST
>
> I am looking at this PR which I was able to
I am looking at this PR which I was able to recreate:
https://issues.apache.org/bugzilla/show_bug.cgi?id=56729
mod_reqtimeout thinks the body is still being read when it gets called
with mode=AP_MODE_SPECULATIVE during check_pipeline() near the end of
a request
Since all of the handlers processi
if (!r->prev && r->proxyreq != PROXYREQ_PROXY) {
> > if ((servername = SSL_get_servername(ssl,
> > TLSEXT_NAMETYPE_host_name))) {
> > char *host, *scope_id;
> > apr_port_t port;
> >
> >
> > This path in the post-read-request
AMETYPE_host_name))) {
> char *host, *scope_id;
> apr_port_t port;
>
>
> This path in the post-read-request hook is performing some SNI-related error
> checking, catching situations where it will return 400 or 403.
>
> I noticed with StrictSNIVHostCheck fa
-if (r->proxyreq != PROXYREQ_PROXY) {
+if (!r->prev && r->proxyreq != PROXYREQ_PROXY) {
if ((servername = SSL_get_servername(ssl,
TLSEXT_NAMETYPE_host_name))) {
char *host, *scope_id;
apr_port_t port;
This path in the post-read-request h
On Fri, Jun 08, 2012 at 08:19:22AM -0400, Jeff Trawick wrote:
> On Fri, Jun 8, 2012 at 4:58 AM, Joe Orton wrote:
> > Yes, but that was exactly the previous state: the security implication
> > of doing crazy stuff with rewrite rules really is totally unknown. I
> > wouldn't say "infrequently used
On Fri, Jun 8, 2012 at 4:58 AM, Joe Orton wrote:
> On Thu, Jun 07, 2012 at 01:14:37PM -0400, Jeff Trawick wrote:
>> On Thu, Jun 7, 2012 at 11:55 AM, Joe Orton wrote:
>> > I like Eric's suggestion of an opt-in RewriteOption. This will avoid
>> > having to iterate yet again if the whitelist is eit
On 08.06.2012 10:58, Plüm, Rüdiger, Vodafone Group wrote:
-Original Message-
From: Joe Orton
Sent: Freitag, 8. Juni 2012 10:38
To: dev@httpd.apache.org
Subject: Re: post-CVE-2011-4317 (rewrite proxy unintended
interpolation) rewrite PR's
On Thu, Jun 07, 2012 at 01:23:29PM -0400,
> -Original Message-
> From: Joe Orton
> Sent: Freitag, 8. Juni 2012 10:38
> To: dev@httpd.apache.org
> Subject: Re: post-CVE-2011-4317 (rewrite proxy unintended
> interpolation) rewrite PR's
>
> On Thu, Jun 07, 2012 at 01:23:29PM -0400, Eric Covener wrote
On Thu, Jun 07, 2012 at 01:14:37PM -0400, Jeff Trawick wrote:
> On Thu, Jun 7, 2012 at 11:55 AM, Joe Orton wrote:
> > I like Eric's suggestion of an opt-in RewriteOption. This will avoid
> > having to iterate yet again if the whitelist is either too broad or too
> > narrow, and can make the secur
On Thu, Jun 07, 2012 at 01:23:29PM -0400, Eric Covener wrote:
> e.g. RewriteOptions +"I know I'm running this regex against something
> that's not guaranteed to look like a URL-path, and I'll write a regex
> that carefully matches/captures the input"
How about this? I'm not sure how to put the ri
> -Original Message-
> From: Eric Covener []
> Sent: Donnerstag, 7. Juni 2012 19:23
> To: dev@httpd.apache.org
> Subject: Re: post-CVE-2011-4317 (rewrite proxy unintended
> interpolation) rewrite PR's
>
> On Thu, Jun 7, 2012 at 1:14 PM, Jeff Trawick wrote:
On Thu, Jun 7, 2012 at 1:14 PM, Jeff Trawick wrote:
> On Thu, Jun 7, 2012 at 11:55 AM, Joe Orton wrote:
>> On Wed, Jun 06, 2012 at 09:08:02PM -0400, Jeff Trawick wrote:
>>> Here are some valid requests which fail the 4317 checks:
>>>
>>> CONNECT foo.example.com[:port]
>>> GET http://foo.example.c
On Thu, Jun 7, 2012 at 11:55 AM, Joe Orton wrote:
> On Wed, Jun 06, 2012 at 09:08:02PM -0400, Jeff Trawick wrote:
>> Here are some valid requests which fail the 4317 checks:
>>
>> CONNECT foo.example.com[:port]
>> GET http://foo.example.com
>> GET proxy:http://foo.example.com/ (rewriting someth
On Wed, Jun 06, 2012 at 09:08:02PM -0400, Jeff Trawick wrote:
> Here are some valid requests which fail the 4317 checks:
>
> CONNECT foo.example.com[:port]
> GET http://foo.example.com
> GET proxy:http://foo.example.com/(rewriting something which was
> already proxied internally)
>
> I am lea
On Sat, May 26, 2012 at 9:19 AM, Rainer Jung wrote:
> On 24.05.2012 17:12, Eric Covener wrote:
>>
>> There are a couple of PR's going around about people who were using
>> rewrite to operate on URL's now kicked out of mod_rewrite by default
>> (IIRC at least proxy:blah and CONNECT arg)
>>
>> Shoul
On 24.05.2012 17:12, Eric Covener wrote:
There are a couple of PR's going around about people who were using
rewrite to operate on URL's now kicked out of mod_rewrite by default
(IIRC at least proxy:blah and CONNECT arg)
Should we just add a mod_rewrite directive or RewriteOption that opts
in to
There are a couple of PR's going around about people who were using
rewrite to operate on URL's now kicked out of mod_rewrite by default
(IIRC at least proxy:blah and CONNECT arg)
Should we just add a mod_rewrite directive or RewriteOption that opts
in to handling any URL and document the cautions
On 11/26/2010 6:57 AM, Oden Eriksson wrote:
> Hello.
>
> We're currenty experiencing a strange segfault in Mandriva Cooker (the
> development branch) with the latest apache-2.2.17, gcc-4.5.1 and all that.
>
> Compiling apache using "-DDEBUG=1 -DAPR_BUCKET_DEBUG=1 -DAPR_RING_DEBUG=1" or
> withou
Hello.
We're currenty experiencing a strange segfault in Mandriva Cooker (the
development branch) with the latest apache-2.2.17, gcc-4.5.1 and all that.
Compiling apache using "-DDEBUG=1 -DAPR_BUCKET_DEBUG=1 -DAPR_RING_DEBUG=1" or
without "-fomit-frame-pointer" makes the segfault go away. This
On Tue, Mar 9, 2010 at 7:45 AM, simon simon wrote:
> Hi,
> Many thanks for the tip
> I have two modules, one have received the body with ap_get_client_block()(I
> have no source), it handle the content,
> the other one need dispatch the original body to some servers.
>
> so, I don't know how c
On Mon, Mar 8, 2010 at 11:47 PM, simon simon wrote:
> hi there,
> I am using ap_setup_client_block() and ap_get_client_block() methods of API
> to read POST request, Request body is being read properly, but there is
> another module waiting these data, it never receive
n, Mar 8, 2010 at 11:47 PM, simon simon wrote:
> > hi there,
> > I am using ap_setup_client_block() and ap_get_client_block() methods of
> API
> > to read POST request, Request body is being read properly, but there is
> > another module waiting these
hi there,
I am using ap_setup_client_block() and ap_get_client_block() methods of API
to read POST request, Request body is being read properly, but there is
another module waiting these data, it never receive it (also use
ap_setup_client_block() and ap_get_client_block() methods)
Any ideas can
On Wed, Jan 13, 2010 at 12:01, Graham Leggett wrote:
> On 13 Jan 2010, at 12:39 PM, Sorin Manolache wrote:
>
>> Exactly. I thought of the same thing. However, if this "whatever" is a
>> ap_run_sub_req and the requests passes through mod_proxy, mod_proxy
>> does not include the request body for sub
On 13 Jan 2010, at 12:39 PM, Sorin Manolache wrote:
Exactly. I thought of the same thing. However, if this "whatever" is a
ap_run_sub_req and the requests passes through mod_proxy, mod_proxy
does not include the request body for subrequests.
ap_proxy_http_request in mod_proxy_http.c contains
if
y new request body.
>>
>> For example:
>>
>> The client sends to my server:
>>
>> POST /server_url
>> (main) request body: body_from_client_to_server
>>
>> My server would make a subrequest to a backend:
>>
>> POST /backend_url
>>
1 - 100 of 414 matches
Mail list logo
