6.894 Lab 2: A Web Proxy Server

Web proxy testing FAQ

This following is a list of the possible reasons why your proxy could not pass the tests. Hope it will be helpful to you.

If your programs fails any of the tests, don't panic. Recompile the test-webproxy with DEBUG_WEBPROXY defined to 1 and run your webproxy in gdb for debugging...

Phase 1

Test Phase 1: test if cachable pages are cached...

This test is to check if you have implemented any caching scheme at all. In the test-webproxy program, the server keeps track of which of the cachable pages have been accessed before and denies access to them the second time. Thus if you have caching in your proxy, all the clients will be able to succeed in getting the cachable pages (first time from the server, second time onwards from your proxy).

Warning: Since the http responses from the server are randomly generated, you need to restart your webproxy every time you run this test if you have running webproxy manually in gdb.

Phase 2

Test Phase 2: test if non-cachable pages are NOT cached...

This test is to check if your cache manager caches anything that's not allowed to be cached. In the test-webproxy program, the server randomly changes the responses to a particular URL (if the type of response associated with the URL is not cachable). The client always checks the response it got from the proxy with the actual response data in the server. Therefore, if your proxy caches anything non-cachable, the response the client got will be different from the server and you will get the following error message:

http response (#num) different from the server offset...

Specially, if (#num) is:

5: Your proxy is caching a http response that has "Pragma: no-cache" header
6: Your proxy is caching a http response that is expired
7: Your proxy is caching "HTTP/1.0 404 Not Found" response
8: Your proxy is caching a response whose corresponding request has "Pragma: no-cache" header
9: Your proxy is caching a response whose corresponding request has "Authentication" header
10: Your proxy is caching a response which is the result of a "POST" request

If your proxy fails for #num 10, try this new server.C file. This is because in the original test-webproxy implementation, the client closes the write direction of the socket connection after writing a POST request and the server will wait until it gets EOF from client to start sending reply back to client rather than determining the end of request by the Content-Length header. In the new implementation, the server starts replying to the client as soon as the number of bytes received for the content entity has exceeded the number specified in the Content-Length header.

Phase 3

Phase 3 tests timeout behavior of your webproxy. In the test-webproxy program, the server refuses to read any data from the client has accepted the connection. Your proxy should be able to timeout and disconnect the corresponding client and server.