spdy: comments/readme added/changed

README

@@ -8,9 +8,9 @@ protocol.  The main application must still provide the application
 logic to generate the content.
 
 Additionally, a second, still very experimental library is provided
-for SPDY/HTTP 2.0 support.  libmicrospdy provides a compact API and
-implementation of SPDY server. libmicrospdy currently only implements
-version 3 of SPDY and accepts only TLS connections.
+for SPDY (the base for HTTP 2.0) support.  libmicrospdy provides a
+compact API and implementation of SPDY server. libmicrospdy currently
+only implements partially version 3 of SPDY.
 
 
 Installation
@@ -108,12 +108,10 @@ a file will block all responses with same or smaller priority
 - Find the best way for closing still opened stream (new call or existing)
 - SPDY_is_stream_opened
 - SPDY PING (used often by browsers)
-- SPDY WINDOW_UPDATE - used often by browsers
+- receiving SPDY WINDOW_UPDATE
 - SPDY Settings
 - SPDY PUSH
 - SPDY HEADERS
-- HTTP POST over SPDY and receiving DATA frames
-- HTTP PUT over SPDY
 - SPDY Credentials
 
 Additional ideas for features include:
@@ -132,6 +130,7 @@ Unimplemented API functions of libmicrospdy:
 
 In particular, we should write tests for:
 - Enqueueing responses while considering request priorities.
+- HTTP methods other than GET
 
 
 

src/include/microspdy.h

@@ -42,8 +42,17 @@
  * "platform.h" in the libmicrospdy distribution).<p>
  * 
  * All of the functions returning SPDY_YES/SPDY_NO return
- * SPDY_INPUT_ERROR when any of the parameters are invalid, e.g.,
- * required parameter is NULL.
+ * SPDY_INPUT_ERROR when any of the parameters are invalid, e.g.
+ * required parameter is NULL.<p>
+ * 
+ * The library does not check if anything at the application layer --
+ * requests and responses -- is correct. For example, it
+ * is up to the user to check if a client is sending HTTP body but the
+ * method is GET.<p>
+ * 
+ * The SPDY flow control is just partially implemented: the receiving
+ * window is updated, and the client is notified, to prevent a client
+ * from stop sending POST body data, for example.
  */
 #ifndef SPDY_MICROSPDY_H
 #define SPDY_MICROSPDY_H
@@ -647,8 +656,10 @@ typedef int
  * @param more a flag saying if more data related to the request is
  *        expected to be received. HTTP body may arrive (e.g. POST data);
  *        then SPDY_NewDataCallback will be called for the connection.
- *        It is also possible that more headers/trailers may arrive;
- *        then the same callback will be invoked.
+ *        It is also possible that more headers/trailers arrive;
+ *        then the same callback will be invoked. The user should detect
+ *        that it is not the first invocation of the function for that
+ *        request.
  */
 typedef void (*SPDY_NewRequestCallback) (void * cls,
 					 struct SPDY_Request * request,
@@ -851,7 +862,7 @@ SPDY_set_panic_func (SPDY_PanicCallback cb,
  * 			established	by a client
  * @param sccb callback called when a session is closed
  * @param nrcb callback called when a client sends request
- * @param npdcb callback called when HTTP POST params are received
+ * @param npdcb callback called when HTTP body (POST data) is received
  * 			after request
  * @param cls common extra argument to all of the callbacks
  * @param ... list of options (type-value pairs,

src/spdy2http/proxy.c

@@ -28,6 +28,8 @@
  * is a lot of data pointed from it)
  * - Correct recapitalizetion of header names before giving the headers
  * to curl.
+ * - curl does not close sockets when connection is closed and no
+ * new sockets are opened (they stay in CLOSE_WAIT)
  * @author Andrey Uzunov
  */