ap_proxy_string_read-apr_bucket_read return value
Hi,
Line 2188 in proxy_util.c has:
if (APR_SUCCESS != apr_bucket_read(e, (const char **)response,
len, APR_BLOCK_READ)) {
return rv;
}
should this be:
if (APR_SUCCESS != (rv = apr_bucket_read(e, (const char
**)response, len, APR_BLOCK_READ))) {
return rv;
}
Regards,
Jon
mod_proxy_ftp relative directory bug
Hi, I am running forward proxies using 2.2.0 and 2.2.2. Using diff I have determined there are no differences in the mod_proxy_ftp.c files related to the following. When going to an ftp site: ftp://ftp.example.com/dir1/dir2 mod_proxy_ftp determines a directory exists through the SIZE command and updates the Directory of HREF accordingly. The browser is unsure whether the dir2 is a file or directory so it's base_href location stays at: ftp://ftp.example.com/dir1/ The relative HREF directories and files returned in the directory listing of ftp://ftp.example.com/dir1/dir2 are subsequently relative to ftp:// ftp.example.com/dir1/ and they break in the client browser. This occurs when a site provides a URL ending in a directory without a trailing slash to a user and the user clicks directly on it. Tested using late IE and Firefox. In http a redirect would have been returned to the browser with a trailing slash once the directory is detected. Should the ftp proxy also return a redirect with a trailing slash at the point it has determined a directory exists? e.g. ftp://ftp.example.com/dir1/dir2 - 302 ftp://ftp.example.com/dir1/dir2/ Regards, Jon Snow
Re: mod_proxy_ftp relative directory bug
Nick, What do you mean by 'updates the Directory of HREF accordingly'? Are you trying to say mod_proxy_ftp requests a *different* URL from the origin server? If so, it sounds like a bug. I am saying that the returned directory listing heading has the corrected path with the trailing slash but this heading is purely information from a users point of view. The proxy at this point knows what the correct path should be but does not inform the client either by redirect or adjusting the directory listing to have relative paths of the form: dir2/somefile.txt The proxy does request the same URL from the origin server as typed by the client then determines through a series of ftp commands whether it is a directory or file. That correction, in either http or ftp, is the business of the origin server, not the proxy. For a proxy to issue it would be deeply broken. Problem is the origin server speaks ftp but the client speaks http. The proxy needs to intervene on the clients behalf and convert the ftp response to an http response that the user can 'web browse'. It is the same as the proxy converting the client's http GET request into an assortment of ftp commands that the origin server can understand. Regards, Jon On Wednesday 23 August 2006 00:45, Nick Kew wrote: On Tuesday 22 August 2006 12:26, Jon Snow wrote: When going to an ftp site: ftp://ftp.example.com/dir1/dir2 mod_proxy_ftp determines a directory exists through the SIZE command and updates the Directory of HREF accordingly. What do you mean by 'updates the Directory of HREF accordingly'? Are you trying to say mod_proxy_ftp requests a *different* URL from the origin server? If so, it sounds like a bug. The browser is unsure whether the dir2 is a file or directory so it's base_href location stays at: ftp://ftp.example.com/dir1/ That's entirely right if the server didn't issue a redirect. In http a redirect would have been returned to the browser with a trailing slash once the directory is detected. Should the ftp proxy also return a redirect with a trailing slash at the point it has determined a directory exists? That correction, in either http or ftp, is the business of the origin server, not the proxy. For a proxy to issue it would be deeply broken.
Re: mod_proxy_ftp relative directory bug
I was thinking along the lines of the following patch. The mod_proxy_ftp
developer should be able to do a much better job
as I am not a coder. It seems to work alright for anonymous and authenticated
ftp traversal and is a good proof of concept.
I can supply a patch for 2.2.3 if required but I need to upgrade my test proxy
first, plus I need sleep now.
Regards,
Jon
--- /dev/httpd-2.2.0/modules/proxy/mod_proxy_ftp.c.dist 2006-08-22
20:21:33.0 +1000
+++ /dev/httpd-2.2.0/modules/proxy/mod_proxy_ftp.c.new 2006-08-23
04:39:19.0 +1000
@@ -292,13 +292,15 @@
apr_status_t rv;
register int n;
-char *dir, *path, *reldir, *site, *str, *type;
+char *dir, *path, *reldir, *site, *str, *type, *location_header;
const char *pwd = apr_table_get(r-notes, Directory-PWD);
const char *readme = apr_table_get(r-notes, Directory-README);
+const char *location = apr_table_get(r-notes, Redirect-REQ);
proxy_dir_ctx_t *ctx = f-ctx;
+
if (!ctx) {
f-ctx = ctx = apr_pcalloc(p, sizeof(*ctx));
ctx-in = apr_brigade_create(p, c-bucket_alloc);
@@ -398,24 +400,54 @@
APR_BRIGADE_INSERT_TAIL(out, apr_bucket_pool_create(str, strlen(str),
p,
c-bucket_alloc));
-/* print README */
-if (readme) {
+ /* Do we need a location header ( redirect ) ? */
+ if ( location )
+ {
+
+ /* Set a temporary redirect */
+ r-status_line = 302 Found;
+
+ /* Concatenate the domain and url then set the Location header*/
+ location_header = apr_pstrcat(p, site, path, NULL);
+ apr_table_setn(r-headers_out, Location, ap_escape_uri(p,
location_header));
+
+ ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,
+ FTP REDIRECT: %s, ap_escape_uri(p, ap_escape_uri(p,
location_header)));
+
+ /* Add the typical redirect content */
+ str = apr_psprintf(p, The document has moved
a.href=\%s\here\n/a/prepre\n, ap_escape_uri(p, location_header));
+
+ APR_BRIGADE_INSERT_TAIL(out, apr_bucket_pool_create(str,
+ strlen(str), p,
+ c-bucket_alloc));
+
+ /* No need to return a body although we did get a listing */
+ ctx-state = FOOTER;
+
+ }
+else {
+ /* print README */
+ if (readme) {
str = apr_psprintf(p, %s\n/pre\n\nhr /\n\npre\n,
ap_escape_html(p, readme));
APR_BRIGADE_INSERT_TAIL(out, apr_bucket_pool_create(str,
strlen(str), p,
c-bucket_alloc));
-}
+ }
+
+ ctx-state = BODY;
+
+ }
/* make sure page intro gets sent out */
APR_BRIGADE_INSERT_TAIL(out, apr_bucket_flush_create(c-bucket_alloc));
if (APR_SUCCESS != (rv = ap_pass_brigade(f-next, out))) {
-return rv;
-}
-apr_brigade_cleanup(out);
+ return rv;
-ctx-state = BODY;
+
+apr_brigade_cleanup(out);
+}
}
/* loop through each line of directory */
@@ -1481,6 +1513,9 @@
rc = proxy_ftp_command(apr_pstrcat(p, CWD ,
ftp_escape_globbingchars(p, path), CRLF, NULL),
r, origin, bb, ftpmessage);
+
+apr_table_set(r-notes, Redirect-REQ, true);
+
/* possible results: 250, 421, 500, 501, 502, 530, 550 */
/* 250 Requested file action okay, completed. */
/* 421 Service not available, closing control connection. */
Re: High CPU utilization on using Apache as a reverse proxy
Pradeep, HP-UX will not be affected by the SSL card issue as it was SUN hardware/driver issue that caused the CPU to spin. I would upgrade to the latest apache version 2.2.3 to eliminate any bugs that may have already been fixed. There were a couple of ssl related ones fixed in 2.0.56 for mod_proxy_http and mod_ssl. Regards, Jon On Saturday 19 August 2006 02:04, pradeep kumar wrote: Hi Jon, Sorry if i mislead you into assuming that I am using Solaris. I am using HP-UX 11iv2. Is HP-UX also affected? In this case also SSL is being used. Regards, Pradeep
Re: High CPU utilization on using Apache as a reverse proxy
Pradeep, I can't remember if I posted the results of the SSL issue and high CPU usage. We tracked it to a bug in the solaris driver for the Sun daughter card, some mutex issue if my memory serves me correctly. Sun confirmed and issued a patch a while ago. As discussed in the quoted post I did not believe it was an apache issue for the SSL but I showed dumps for a corresponding write issue with a forward proxy in an early anticipation it may be related. This forward proxy problem I had sounds similar to your issue where apache appears not to test a return value for a write but it did not utilise large CPU. Currently I run 2.2.2 and have observed the same write problem as I did with 2.0.53. One main issue I have with this is the download continues while the write fails so effectively the active connection is not in sound communication with the passive. I put the huge memory usage down to the byte range bug as these processes were nearly always streaming or FTPing large files. I have not seen this memory usage with the version I am running even when I see the write problem. To clarify your issue are you running SSL and if so are you using hardware crypto? I assume you are using solaris, is it patched for crypto re: above and what version of solaris are you using? Regards, Jon On Tuesday 15 August 2006 00:47, pradeep kumar wrote: Hi, I notice there is a 100% CPU utilization which spikes for sometime and then goes back to normalcy when Apache is used a reverse proxy. I noticed a mail thread which seems to be a similar problem http://mail-archives.apache.org/mod_mbox/httpd-dev/200510.mbox/%3C200510252 [EMAIL PROTECTED] One thread of one of the child processes hangs, calling poll() and writev() system calls so frequently that it causes 100% CPU util. The thread is trying to writev() to a socked which is in CLOSE_WAIT The child process ends after time defined by ndd parameter tcp_keepalive_interval and the same service time can be seen in access_log. The problem disappears then. Regards, Pradeep
rproxy close_wait high cpu
Hi,
I am running solaris 8 with apache 2.0.53 over openssl 0.9.7 as a reverse
proxy which terminates and reestablishes SSL to the backend. I run the worker
mpm with 100 threads per process. The server has minimal load and uses a
crypto card. The build is pretty minimal and runs in a gateway environment.
I have had alot of issues with processes going into a high cpu state. These
are always associated with close_wait state connections and nearly all the
time all the connections are close_wait. Would this suggest something shared
is affecting all connections/threads in the process?
After trolling through 50Gb of snoop dumps I have found that the latest appear
associated with an outbound SSL session that does not fully establish. These
outbound connections receive the server certificate and should send the
client key/cipher exchange but nothing follows. The client to proxy session
is normal and the request has been received by the proxy, the proxy does not
establish SSL properly to the server and as such the proxy does not forward
the request.
In the mean time the client and server ends time out (120s approx) and send a
fin which the proxy acks. In both instances the proxy does not return a fin,
nor does it timeout. At some point the process goes high CPU. This is very
repeatable on a server with a load of around 10-15 connections per second and
may occur on average 1-2 times a day. Unfortunately this thing is killing us
on a highly political service.
While it appears SSL is the cause, apache does not seem to be handling the
situation very well. It looks like apache knows it has data to send to the
server and data to return to the client so it does not close it's side of the
socket. At some point it must go into some sort of loop trying to recover I
guess.
I can't recall truss returning anything on these reverse proxy runaway
processes but I managed to get a truss of a forward proxy using heaps of
memory. It looks like apache is not checking the return value on it's write.
From memory in this instance there was no longer an inside connection but
apache was still trying to write to one. The forward proxy servers also
suffer from close_waits when using huge memory but do not suffer from high
cpu. I am thinking the same kind of issue may exist with the reverse proxy
where it loops to read/write a closed socket without checking the return
value resulting in the high cpu.
I have now turned on debug logging for the SSL diag but does anyone have any
idea what may be going on here with apache and the high cpu? When does the
connection timer start, before the connection is attempted or after it is
established? Is there any more info you need?
Thanks,
Jon
Forward Proxy stuff
###
16786: writev(128, 0x7440C860, 6) Err#32 EPIPE
16786: write(6, 0x7440A510, 99)= 99
16786: [ T u e A p r 1 9 0 8 : 2 7 : 3 1 2 0 0 5 ] [ i n f o
16786: ] ( 3 2 ) B r o k e n p i p e : c o r e _ o u t p u t _ f
16786: i l t e r : w r i t i n g d a t a t o t h e n e t w o
16786: r k\n
16786: lwp_sigredirect(0, SIGPIPE, 0x) = 0
16786: poll(0x7440C3C0, 1, 30) = 1
16786: read(131, C9 nF216 R 08DF303CFE7 F.., 8000) = 1360
16786: poll(0x7440C3C0, 1, 30) = 1
16786: read(131, 11 1 # ; GF9FD + T04 e R.., 8000) = 1360
16786: poll(0x7440C3C0, 1, 30) = 1
16786: read(131, 10 91C f94 I93D2A6CD15 {.., 8000) = 1360
16786: poll(0x7440C3C0, 1, 30) = 1
16786: read(131, AEE8C78F9504B8 VF607918C.., 8000) = 1360
16786: poll(0x7440C3C0, 1, 30) = 1
16786: read(131, 0 r K\0 UB0A0\fF3C8 l93.., 8000) = 1360
16786: poll(0x7440C3C0, 1, 30) = 1
16786: read(131, \ `1EA4D51BCF % /A7 .F3.., 8000) = 1360
16786: signotifywait() = 13
16786: writev(128, 0x7440C860, 6) Err#32 EPIPE
16786: write(6, 0x7440A510, 99)= 99
16786: [ T u e A p r 1 9 0 8 : 2 7 : 3 2 2 0 0 5 ] [ i n f o
16786: ] ( 3 2 ) B r o k e n p i p e : c o r e _ o u t p u t _ f
16786: i l t e r : w r i t i n g d a t a t o t h e n e t w o
16786: r k\n
16786: lwp_sigredirect(0, SIGPIPE, 0x) = 0
16786: poll(0x6DA063C0, 1, 30) = 1
16786: read(45, 11BE K1501 w01C1 = + Z X.., 8000)= 4080
16786: signotifywait() = 13
16786: writev(70, 0x6DA06860, 5) Err#32 EPIPE
16786: write(6, 0x6DA04510, 99)= 99
16786: [ T u e A p r 1 9 0 8 : 2 7 : 3 3 2 0 0 5 ] [ i n f o
16786: ] ( 3 2 ) B r o k e n p i p e : c o r e _ o u t p u t _ f
16786: i l t e r : w r i t i n g d a t a t o t h e n
Mapping proxy inbound to outbound connections
Hi, I want to tie together the inbound and outbound connections for a forward or reverse proxy session. I figured I would add the source ports to the log which would enable me to track the connections through firewall logs etc. based on addressing/port combinations. I was looking at writing a module/ filter to do this. Would this be possible and the best way to go or would there be an easier way? Thanks, Jon
mod_proxy_ftp BASE REF
Does anyone have any idea why/whether the BASE HREF is required in the proxy_ftp html code returned to the client? I would like to remove it as it is breaking relative links for my client's browsers that are not using an Authorization header. I have not found anywhere in the RFCs where it is stipulated as a must for the BASE HREF or that browsers must use the authorization header for requests subsequent to the initial authorization using the user:password combination in the URL. e.g. ftp:// user:[EMAIL PROTECTED] Thanks, Jon
Re: mod_proxy_ftp BASE REF
Graham, Thanks. This patch definately will do the trick as I have already applied the same to test it. The browser reuses the original user:[EMAIL PROTECTED] syntax for each subsequent relative URL access. This results in the same behaviour as using a squid proxy which does not use a base href. As yourself and Nick cannot find a reason for the base href either I feel more confident to patch our production systems without breaking anything. I am unsure whether this would be considered a bug or not though without feedback from the original implementor. In my mind it doesn't seem to make sense, in normal operation, to rewrite content on a proxy overriding the client's view of the world. Any opinions on whether this would be considered a bug? Regards, Jon On Tuesday 09 August 2005 20:37, Graham Leggett wrote: Jon Snow wrote: Does anyone have any idea why/whether the BASE HREF is required in the proxy_ftp html code returned to the client? I would like to remove it as it is breaking relative links for my client's browsers that are not using an Authorization header. I have not found anywhere in the RFCs where it is stipulated as a must for the BASE HREF or that browsers must use the authorization header for requests subsequent to the initial authorization using the user:password combination in the URL. e.g. ftp:// user:[EMAIL PROTECTED] Also see no reason for the base href. Does this patch do the trick for you? Regards, Graham -- ftp.patch Index: modules/proxy/mod_proxy_ftp.c === --- modules/proxy/mod_proxy_ftp.c (revision 231016) +++ modules/proxy/mod_proxy_ftp.c (working copy) @@ -352,11 +352,10 @@ /* print ftp://host/; */ str = apr_psprintf(p, DOCTYPE_HTML_3_2 html\n head\n title%s%s%s/title\n - base href=\%s%s%s\\n /head\n + /head\n body\n h2Directory of a href=\/\%s/a/%s, site, basedir, ap_escape_html(p, path), -site, basedir, ap_escape_uri(p, path), site, str); APR_BRIGADE_INSERT_TAIL(out, apr_bucket_pool_create(str, strlen(str),
proxy_ftp base href breaks authorization
Hi, I run a forward proxy using mod_ftp_proxy through a forward proxy heirarchy. The proxy in question is the last in the chain and communicates with the Internet. Mod_proxy_ftp will successfully return a directory listing after authentication to an FTP site using a user:password combination in the URL. The listing html code includes a BASE HREF tag in the HEAD section returned in the response to the client. This BASE HREF contains the form ftp:// [EMAIL PROTECTED] This overrides the browser base retrieving URL and as there is no password included there is a further requirement for an alternate method of authentication otherwise the client will need to authenticate for every link that is selected. On most browsers I have tested (mozilla, firefox, konqueror) this will be done with the Authorization: header and will work through the proxy but unfortunately not on my client's IE 6.0 build. There is no Authorization header supplied on the initial or subsequent requests and so every time a link in the FTP listing is selected the authentication process is repeated. I am assuming at this stage this problem is particular to my client's IE build but I am questioning the use of the BASE HREF. I would have thought if a BASE HREF is returned it would be of the form ftp://user:[EMAIL PROTECTED] but as the browser already knows this as it's base URL there would be no requirement for the BASE HREF in the returned html anyway. The current BASE HREF without the password is breaking the links when the Authorization header is not being used, but whether the header is used or not the BASE HREF URL provides no additional information to the browser. I have removed the BASE part in the proxy module code and this gets around the problem as the browser sends the user:password in the URL. This then simulates squid behaviour. Does anyone have any idea why/whether the BASE HREF is required in the proxy_ftp html code returned to the client? Thanks, Jon
