| description |
I need a lightweight proxy server suitable for simulating network failures and other common problems which interfere with the successful operation of REST-style client-server APIs. Under normal use, the proxy server will behave identically to Apache's mod_proxy, in that it should accept HTTP requests and forward them along to a specified remote service, then collect the response, rewriting the content and headers as necessary, and return them to the client. However, the proxy server will also listen on a configurable control port and expose a web-based configuration interface which allows the behavior to be altered. The servers being proxied will be capable of supporting over 350 requests per second; with this proxy in place clients shouldn't see more than a 1% impact on the overall performance unless the behavior is being altered as described below:
1. Spontaneous close. A configurable percentage of the connections should close spontaneously before all the response bytes have been written.
2. Reject connections. A configurable percentage of the connections should be refused.
3. Slow response. A configurable percentage of the requests should be responded to slowly. This means that there will be a lag between response bytes although all of the data in the response will be eventually sent.
4. Specified HTTP response code.
These should be combinable; it should be possible to specify that a percentage of the responses are normal, another percentage are responded to properly but take 30 seconds to return all the data, another percentage should be dropped spontaneously, another percentage should return HTTP response code 404, etc. In addition, it should be possible to have the system randomly select upon a set of response alternatives, which should provide more "real-world" testing. You have the ability to define the syntax for specifying these parameters. The parameters must be editable through the control port/GUI and should also be able to be initialized from the command line or via a properties file (your choice).
The UI should have the ability to display statistics in the following areas:
A. Number of connections refused
B. Number of requested connections not accepted
C. Total number of requests
D. Total number of 200 responses
E. Total number of non-200 response
F. Transfer rate for 200 responses
I prefer a Java servlet suitable for deployment under Tomcat or Jetty but would accept code written in any language so long as the performance characteristics outlined above are satisfied.
Additional requirements:
1. The proxy server must support Keep-Alives for HTTP connections and must properly return (and rewrite, if needed) the Content-Length header if it is returned from the proxied service.
2. The proxy server must rewrite (as does mod_proxy) URLs in the response data and headers which refer back to the underlying service. show/hide addendum
|
|
1. Code must be developed and demonstrated on your own linux web server, using my input files and producing specified output files.
2. Code should be concise; no repeated blocks, no files read more than once if not necessary, etc.
3. Copyright will be owned by me; I will credit you in the source code and/or on my webpage.
4. You should strive to use open source components as appropriate, choosing components based on popularity and reliability, amount of active development, etc. You must list all open source or other components used for my project, and verify that we have rights to later use them commercially if I choose.
5. Once I approve the output, send me a zipfile containing and source code, and a Makefile with these components:
* a comment on the purpose of each file.
* a comment with a pointer to your webpage which demonstrates your successful use of the program.
* a target of "run" which runs the program with appropriate input and output files specified.
* a target of "clean" which removes all output and temporary files.
* any appropriate "install-xxx" targets to download and install any required components from the net.
6. I will then the code on my linux server using your Makefile; and must verify that it produces the correct output on my server.
7. For C-like programming languages (Java, JavaScript, Perl, PHP, Ruby, etc.), please use the following conventions:
a) Use a programmer's editor that does automatic formatting, e.g., emacs.
b) Keep all lines less than 78 characters long. (If you absolutely need to have a long line, consider putting a blank line above and below it, to make it easier to read.)
c) Use two spaces for indentation level. (Wider indents would make more lines wrap.)
d) Make all inline comments start in the same column when possible. I.e., in emacs try M-; to run indent-for-comment.
e) Use a 65-dash comment to separate sections, e.g., for Perl:
# -----------------------------------------------------------------
# subroutines/functions/methods:
f) Most subroutines should be less than about 50 lines of code.
g) Usually put a space before any open parens, and after every comma and semi-colon, and on either side of built-in operators like the = sign.
h) Do not put two statements on one line.
i) Open brace at end of line like this:
if condition {
action();
}
j) Always follow an if/for/while clause with {} to wrap the actions, even if there is only one statement as the action.
|
