|
Line
Link Here
|
| 0 |
-- modules/proxy/mod_proxy_ftp.c.orig 2012-12-05 07:22:05.000000000 -0600 |
0 |
++ modules/proxy/mod_proxy_ftp.c.bugfixchanges 2012-12-05 12:41:21.000000000 -0600 |
|
Lines 1909-1914
Link Here
|
| 1909 |
rc = proxy_ftp_command(NULL, r, origin, bb, &ftpmessage); |
1909 |
rc = proxy_ftp_command(NULL, r, origin, bb, &ftpmessage); |
| 1910 |
apr_brigade_cleanup(bb); |
1910 |
apr_brigade_cleanup(bb); |
| 1911 |
|
1911 |
|
|
|
1912 |
/* ----------------------------------------------------------------- |
| 1913 |
* Need to deal with '426' from FTP: |
| 1914 |
* |
| 1915 |
* responses: 426 |
| 1916 |
* |
| 1917 |
* 426 Failure writing network stream |
| 1918 |
* |
| 1919 |
* Use case: Seems to happen when a user cancels a download proxied |
| 1920 |
* through an FTP server with mod_proxy. I think the initial problem |
| 1921 |
* occurs up above at line 1630 where the HTTP retval gets set to |
| 1922 |
* 'HTTP_OK' (200 OK) automatically and IMHO shouldn't log a '200' in |
| 1923 |
* the access_log as so. |
| 1924 |
* |
| 1925 |
* This is the last where the last and final response from the FTP |
| 1926 |
* server gets handled, so we should do something with it and at least |
| 1927 |
* log it properly. |
| 1928 |
* |
| 1929 |
* '499' HTTP_CLIENT_CLOSED_REQUEST is an Nginx HTTP1/1 retval, not |
| 1930 |
* specifically outlined in the RFC 2616. I thought it was applicable |
| 1931 |
* and did add it to include/httpd.conf |
| 1932 |
* |
| 1933 |
* Adam Dosch - 12/5/2012 |
| 1934 |
* |
| 1935 |
*/ |
| 1936 |
|
| 1937 |
if (rc == 426 ) { |
| 1938 |
r->status = HTTP_CLIENT_CLOSED_REQUEST; |
| 1939 |
r->status_line = "499"; |
| 1940 |
} |
| 1941 |
|
| 1942 |
/* ----------------------------------------------------------------- */ |
| 1943 |
|
| 1912 |
/* |
1944 |
/* |
| 1913 |
* VII: Clean Up ------------- |
1945 |
* VII: Clean Up ------------- |
| 1914 |
* |
1946 |
* |