gecko-dev/netwerk/test/httpserver/TODO

Bugs to fix:
- make content-length generation not rely on .available() returning the entire
  size of the body stream's contents -- some sort of wrapper (but how does that
  work for the unscriptable method WriteSegments, which is good to support from
  a performance standpoint?)

Ideas for future improvements:
- add API to disable response buffering which, when called, causes errors when
  you try to do anything other than write to the body stream (i.e., modify
  headers or status line) once you've written anything to it -- useful when
  storing the entire response in memory is unfeasible (e.g., you're testing
  >4GB download characteristics)
- add an API which performs asynchronous response processing (instead of
  nsIHttpRequestHandler.handle, which must construct the response before control
  returns; |void asyncHandle(request, response)|) -- useful, and can it be done
  in JS?
- other awesomeness?
Bug 342877 - Substantially revamp/rewrite the testing-only HTTP server used in necko unit tests, making it suitable for use in Mozilla tests which require files be stored on an HTTP server (e.g. because the test depends on certain HTTP headers being set or not set, the functionality uses HTTP, etc.) but which don't require that the server have a specified hostname. Docs, implementation, and tests (!) are in netwerk/test/httpserver/; if you have questions about using the server in unit tests or have some use case which the server could support better or doesn't support at all, CC me on the bug and I'll see how I can help. Huge (huge) thanks to biesi for the review of the huge patch. r=davel on test-harness changes, r=biesi on the server and test changes 2006-12-15 05:13:54 +03:00			`Bugs to fix:`
			`- make content-length generation not rely on .available() returning the entire`
			`size of the body stream's contents -- some sort of wrapper (but how does that`
			`work for the unscriptable method WriteSegments, which is good to support from`
			`a performance standpoint?)`

			`Ideas for future improvements:`
			`- add API to disable response buffering which, when called, causes errors when`
			`you try to do anything other than write to the body stream (i.e., modify`
			`headers or status line) once you've written anything to it -- useful when`
			`storing the entire response in memory is unfeasible (e.g., you're testing`
			`>4GB download characteristics)`
			`- add an API which performs asynchronous response processing (instead of`
			`nsIHttpRequestHandler.handle, which must construct the response before control`
			`returns; \|void asyncHandle(request, response)\|) -- useful, and can it be done`
			`in JS?`
			`- other awesomeness?`