#this file was earlier called todo.txt and contains low level todo's. #However since Windows folks couldnt unzip it, therefore renamed. Persistent Connections: check version: if 1.0 if keep-alive then dont close else close else if 1.1 if close then close else keep open Pipelining: Dont switch off read interest at all even after write. You may get 2 requests in one shot, so you need to break a request also. However, order of write is to be maintained. In a MT, environment, this becomes a little more involved. when a request needs to write data, we are first reading it up from disk, cahing it, and them giving it to the caller. this means that for a very large file, we cannot send data in chunks. In the case of a range request of a non-cached file, we wuold read the whole thing up. We would have to pass in a handle for the program to write away (handle of nio or of pipelined writer). Logging. Some of this will be cached too. Get out the format used by HttpServers (apache). ---- I thought byte ranges were trivial - here's what the spec says: Range: If a syntactically valid byte-range-set includes at least one byte- range-spec whose first-byte-pos is less than the current length of the entity-body, or at least one suffix-byte-range-spec with a non- zero suffix-length, then the byte-range-set is satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server SHOULD return a response with a status of 416 (Requested range not satisfiable). Otherwise, the server SHOULD return a response with a status of 206 (Partial Content) containing the satisfiable ranges of the entity-body. Examples of byte-ranges-specifier values (assuming an entity-body of length 10000): - The first 500 bytes (byte offsets 0-499, inclusive): bytes=0- 499 - The second 500 bytes (byte offsets 500-999, inclusive): bytes=500-999 - The final 500 bytes (byte offsets 9500-9999, inclusive): bytes=-500 - Or bytes=9500- - The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1 - Several legal but not canonical specifications of the second 500 bytes (byte offsets 500-999, inclusive): bytes=500-600,601-999 bytes=500-700,601-999 ---- After the recent rework on HttpPro and File/URl, i am once again gettig that block on setSendData which results in the last connection not getting serviced, till another one comes along. When the client disconnected, there wud be a CancelledKeyExc. Seems to have gone by timing out the start/select() frin AdvServer. Need to go thru code carefully. Is this because of threads, or has this just come up. (Server.java doesnt suffer from this hangup). Should load processor from file, make it HttpProcessor Interface for FileInfo and URLcache, so both these are pluggable. s.setSoTimeout(Server.timeout) while bind(), to also define the backlog (from file). BIGGEST TODO's are pipelining and persistent connections, as these may change NioSocket also. all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies. -- HTTP/1.1 applications that do not support persistent connections MUST include the "close" connection option in every message. persistent connections: close tag Origin servers MUST include a Date header field in all responses, except in these cases: next should be configurable to avoid security vulnerabilities Server: CERN/3.0 libwww/2.17 RFC822 headers - done with dates. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15). -- --- All HTTP/1.1 applications MUST be able to receive and decode the "chunked" transfer-coding, and MUST ignore chunk-extension extensions they do not understand. # 2003-11-29 handle mime types The server would be another project, called NioHttpServer, and be a dev release. Since the socket blaster uses the protocol classes, i think, therefore i may have a problem in making a separate project of that. - File based NIO - Give the option of connect and read timeouts so that unresponsive/hung/loaded servers performance can be logged. Perhaps NioSocket shd be simplified. I shd extend NioSocket and add read_complete, write_complete and handle_terminate there. If a user wants to process handle_read as data comes, this would confuse and make it difficult for him. Also, in Nio we forgot to buffer the output, assuming it would be small (4096). Allow for size to be set. Add output buffering also. - DONE check return value: 200 is okay. we need to log errors so that users knows (particularly in SocketBlaster) that the server couldnt handle. 1. -1 with 0 bytes 2. Errors like 500,5* etc. Need to tabulate how many of each we got. create a handler and pass that Put option handling into a class so we can adde to that optimize SB, so that all repetitive tasks are done once only. (DONE) Then add options to it for repeated bursts and incremental bursts. logging how many could not make it (refused) etc users may want to go through proxy for some urls and bypass for some. we cd take care of that. (PROXY HANDLING IS NOT OUR PRIORITY HERE!!!)