diff --git a/changelog b/changelog
index 2ab975bc..05880533 100644
--- a/changelog
+++ b/changelog
@@ -33,7 +33,10 @@ the peak allocation.
 
 Setting max_http_header_pool to 1 is fine it will just queue incoming
 connections before the accept as necessary, you can still have as many
-simultaneous post-header connections as you like.
+simultaneous post-header connections as you like.  Since the http header
+processing is completed and the allocation released after ESTABLISHED or the
+HTTP callback, even with a pool of 1 many connections can be handled rapidly.
+
 
 User api changes
 ----------------
@@ -41,9 +44,9 @@ User api changes
 1) LWS_SEND_BUFFER_POST_PADDING is now 0 and deprecated.  You can remove it; if
 you still use it, obviously it does nothing.  Old binary code with nonzero
 LWS_SEND_BUFFER_POST_PADDING is perfectly compatible, the old code just
-allocated a buffer bigger than needed.
+allocated a buffer bigger than the library is going to use.
 
-The example apps no longer user it.
+The example apps no longer use LWS_SEND_BUFFER_POST_PADDING.
 
 The only path who made use of it was sending with LWS_WRITE_CLOSE.
 
diff --git a/lib/libwebsockets.h b/lib/libwebsockets.h
index f4761e96..807087d1 100644
--- a/lib/libwebsockets.h
+++ b/lib/libwebsockets.h
@@ -32,8 +32,6 @@
 #include "sal-stack-lwip/lwipv4_init.h"
 
 namespace {
-	const int SERVER_PORT = 80;
-	const int BUFFER_SIZE = 4096;
 }
 using namespace mbed::Sockets::v0;
 
@@ -64,7 +62,6 @@ public:
 
 public:
 	struct lws *wsi;
-	char buffer[BUFFER_SIZE];
 	char writeable;
 	char awaiting_on_writeable;
 };