[Bug 57044] [PatchAvailable] Use base64url in mod_unique_id ('_' instead of '@')

2020-12-01 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=57044

--- Comment #4 from Dmitry A. Bakshaev  ---
actual rfc is 4648: https://tools.ietf.org/html/rfc4648#section-5

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org



[Bug 64949] New: Server denies requests from network

2020-12-01 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=64949

Bug ID: 64949
   Summary: Server denies requests from network
   Product: Apache httpd-2
   Version: 2.5-HEAD
  Hardware: HP
OS: Linux
Status: NEW
  Severity: trivial
  Priority: P2
 Component: mod_access
  Assignee: bugs@httpd.apache.org
  Reporter: hwal...@windev.cc
  Target Milestone: ---

The server returns a "403 Forbidden" when trying to access it via the local
network.

This bug would be fixed by including these lines in the configuration file:


Require all denied



Require all denied



Require all granted


-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org



[Bug 64946] New: Websocket tunnel is created and stay opened even if the handshake failed

2020-12-01 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=64946

Bug ID: 64946
   Summary: Websocket tunnel is created and stay opened even if
the handshake failed
   Product: Apache httpd-2
   Version: 2.4.46
  Hardware: Other
OS: All
Status: NEW
  Severity: blocker
  Priority: P2
 Component: mod_proxy_wstunnel
  Assignee: bugs@httpd.apache.org
  Reporter: valentin.oza...@gmail.com
  Target Milestone: ---

Hi,

We are facing a critical issue with mod_proxy_ws_tunnel : Websocket tunnel is
created and stay opened even if the handshake failed

Here is the observed behavior:

Assumptions: 
- Let’s assume httpd is configured as reverse proxy with 2 backends :
backend_websocket_1 and backend_2 
- The client is a browser that works with a reusable tcp/http connection pool.

Typical issue that occurred
- The Browser try to establish a websocket connection to /backend1
- backend_websocket_1 answers 500 instead 101 during websocket handshake (due
to temporary error)
- The browser received the 500 and considers the websocket connection as failed
- The browser reuse the same tcp connection to send others http requests to
backend_2
- The new http requests (to backend_2 for example) are not catched properly by
httpd and are directly forwarded to backend_websocket_1 (it seems they are
forwaded directly in the previously opened tunnel).

Additional notes: 
We succeeded to reproduce this behavior on many httpd version 2.4.46 included.
We also test the same scenario with an other reverse proxy (haproxy) and
everything works fine

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org