CppCMS Blog http://blog.cppcms.com/ A blog on CppCMS - C++ Web Development Framework CppCMS 1.0.4 Released http://blog.cppcms.com/post/115 http://blog.cppcms.com/post/115 <div style="direction:ltr"> <p>This is a critical bug fix release that relates to session handing in Internet Explorer.</p> <p>Added "Expires" to cookie expiration time handling that is supported by IE.</p> <p>Prior to this release, cppcms session cookies used max-age option, that IE does not recognize. Starting from this release the session cookies would have both Expires and Max-Age options. All browsers that use Max-Age would ignore Expires if both given.</p> <p>New options that control the session cookie properties are added, see <a href="http://cppcms.com/wikipp/en/page/cppcms_1x_config#session.cookies.expiration_method">expiration_method</a> that would allow to alter the behavior and handle possible clock skew issues</p> <p>Special thanks to Saikumar Gandapodi who reported me this issue.</p> </div> Security bug fix release - CppCMS 1.0.3 http://blog.cppcms.com/post/113 http://blog.cppcms.com/post/113 <div style="direction:ltr"> <p>CppCMS 1.0.3 was released today, it includes security bug fix.</p> <p>This bug allowed CppCMS encoding validation to accept some invalid UTF-8 sequences which could potentially lead to various security problems like XSS and more.</p> <p>It is strongly recommended to upgrade to latest version.</p> <p><strong>Note:</strong> for thous who used <code>booster::locale::utf::utf_traits</code> or functions <code>booster::locale::conv::utf_to_utf</code> directly rather than using built in CppCMS forms validation/XSS validation, you may need to recompile the application to get the updates.</p> <p>The release is available on sourceforge and in the official repositories for Ubuntu oneiric, precise and quantal, Debian squeeze, Fedora 16 and 17, Centos 6 and Open Suse 11.4 and 12.1</p> </div> We are under attack... http://blog.cppcms.com/post/112 http://blog.cppcms.com/post/112 <div style="direction:ltr"> <p>Here in Israel...</p> <p>I hear explosions of Grad rockets fired by Hamas to our cities. I hear sirens that gives us <a href="http://youtu.be/gsm-mEy38pQ">short</a> alarms to run for shelters.</p> <p>This is daily routine...</p> <div style="text-align:center"><iframe width="420" height="315" src="http://www.youtube.com/embed/86FdnMIcS1A" frameborder="0" allowfullscreen></iframe></div> <p><a href="http://www.youtube.com/watch?NR=1&amp;v=LxX6f5R4-3E">What Gives Israel the Right to Defend Itself?</a></p> <p><strong>Artyom Beilis,</strong></p> <p><strong>Lead CppCMS Developer, from Israel</strong></p> </div> SVN Repositories Had Moved to New Location http://blog.cppcms.com/post/111 http://blog.cppcms.com/post/111 <div style="direction:ltr"> <p>Due to upgrades on sourceforge the svn repositories had moved. If you are using the version from SVN-Trunk, please checkout them once again:</p> <p>CppCMS</p> <ul> <li><strong>HTTP-Protocol:</strong> http://svn.code.sf.net/p/cppcms/code/framework/trunk</li> <li><strong>SVN-Protocol:</strong> svn://svn.code.sf.net/p/cppcms/code/framework/trunk</li> </ul> <p>CppDB</p> <ul> <li><strong>HTTP-Protocol:</strong> http://svn.code.sf.net/p/cppcms/code/cppdb/trunk</li> <li><strong>SVN-Protocol:</strong> svn://svn.code.sf.net/p/cppcms/code/cppdb/trunk</li> </ul> </div> Server-Sent Events in CppCMS Trunk http://blog.cppcms.com/post/110 http://blog.cppcms.com/post/110 <div style="direction:ltr"> <p>There is a simple class added to the contrib section in trunk.</p> <p><a href="https://cppcms.svn.sourceforge.net/svnroot/cppcms/framework/trunk/contrib/server_side/sse/">https://cppcms.svn.sourceforge.net/svnroot/cppcms/framework/trunk/contrib/server_side/sse/</a></p> <p>The Server-Sent Events support is provide in form of a generic class <code>sse::event_source</code> that the user expected to derive from.</p> <p>Also two simple event source objects with a predefined policy:</p> <ul> <li>Queue bounded up to certain capacity: <code>sse::bounded_event_queue</code></li> <li>Real time state updates that allows to keep clients updated with the latest events - rather than sending all the events from the beginning: <code>sse::state_stream</code></li> </ul> <p>Examples of a simple chat and a stock ticker are provided.</p> <p>Notes:</p> <ul> <li>the <code>sse::event_source</code> supports falling back to long polling using XHR by sending a special header, notifying the server that the connection should be closed rather than kept open.</li> <li>Also the code resides withing trunk, it is fully useful with current stable CppCMS release - 1.0.2.</li> <li>This code does nothing exceptional, you don't really have to use it to create SSE, it is just makes it easy to handle them without knowing too much about server-side event driven programming.</li> </ul> </div> CppCMS 1.0.2 - Bug Fix Release http://blog.cppcms.com/post/109 http://blog.cppcms.com/post/109 <div style="direction:ltr"> <p>CppCMS 1.0.2 Released, it is a bug fix release.</p> <p>Fixed Bugs:</p> <ul> <li>Fixed incorrect HTML generation using <code>as_table</code></li> <li>Fixed build issues with latest ICU: 3540278</li> <li>Fixed some warnings in Boost.Locale</li> <li>Fixed missing error report in case of running out of disk space in file upload: 3542469</li> <li>Fixed visual studio 11 build issues: 3527712,3527702</li> <li>Fixed problem with using automatic type detection in C++11 mode with gcc 3537374</li> <li>Fixed bugs that made stackstream useless</li> <li>Fixed issues build issues on Mac OS X: 3513865</li> <li>Fixed OpenSSL detection on Windows: 3515712</li> <li>Fixed incorrect scgi configuration for nginx in <code>cppcms_run</code></li> </ul> </div> Easy Comet: Server-Sent Events http://blog.cppcms.com/post/107 http://blog.cppcms.com/post/107 <div style="direction:ltr"> <h3>HTML5 Comet Technologies</h3> <p>Today there are two major technologies for efficient implementation of Comet applications using HTML5:</p> <ul> <li><a href="http://en.wikipedia.org/wiki/WebSocket">WebSockets (WS)</a></li> <li><a href="http://www.w3.org/TR/eventsource/">Server-Sent Events (SSE)</a></li> </ul> <p>The first ones - WS - provide full-duplex communication such that both client and server can send each other events without creating a new connection. The second ones - SSE - provide real time notification in a single direction, server to client.</p> <p>It seems that WS is much more popular. Indeed, WS are much more powerful and their support is <a href="http://cppcms.com/wikipp/en/page/cppcms_1x_tasks#Provide.WebSockets.support">scheduled</a> for an implementation in CppCMS. On the other hand, WS have very significant limitation: WS protocol <strong>is not HTTP</strong>. It may look like HTTP and its hand-shake is done at HTTP level, but afterwards, the communication is done using different protocol that is not compatible with HTTP.</p> <p>As a result, there is no way to implement WS over existing web server API as FastCGI or SCGI. More than that, even if the application uses HTTP directly, not every web server would be able to proxy web sockets communication.</p> <p>So, despite that WS is very promising technology, it is very hard to deploy it today in the real production environment.</p> <p>On the other hand, SSE are implemented over plain HTTP without any changes. The protocol is very simple and supported by most browsers, Firefox, Opera, Safari, Chrome and expected to be supported by IE10.</p> <p>There is no special changes required to underlying web server APIs, thus FastCGI or SCGI would work perfectly well. For example, SSE can be easily implemented using stable version of CppCMS without any special tools.</p> <p>Additionally SSE support stream synchronization in case of disconnect. The fall-back to long-polling using XHR can be easily implemented.</p> <h3>An Example</h3> <p>‎Lets implement a simple page that receives stock price updates.</p> <p>First, we create an EventSource object and then we attach a handler that would update the appropriate html filed upon notification from the server side:</p> <pre><code>function read_data() { var stream = new EventSource('/ticker'); stream.onmessage = function(e){ document.getElementById('price').innerHTML=e.data; }; stream.onerror = function(e){ console.log(e); }; } read_data(); </code></pre> <p>The code is very simple and trivial, disconnects are handled automatically and transparently. Now lets take a look on the server side that is little bit more challenging:</p> <p>Upon request we prepare our content type as required and fetch the ID of the last known price that was sent to the client.</p> <pre><code>void main(std::string /*url*/) { response().set_content_header("text/event-stream"); response().set_header("Cache-Control", "no-cache"); auto last_id = atoi(request().cgetenv("HTTP_LAST_EVENT_ID")); </code></pre> <p>After that we detach the HTTP context object from the application, such that we will be able to handle multiple connections simultaneously.</p> <pre><code> auto context=release_context(); </code></pre> <p>The idle connections would be stored in a special <code>waiters_</code> set. We add a special callback that allows us to cleanup the clients that had disconnected:</p> <pre><code> context-&gt;async_on_peer_reset([=](){ this-&gt;waiters_.erase(context); }); </code></pre> <p>Note, we use C++11 lambda expressions that make the code much more simple and clear.</p> <p>Then we check if the last price id that is known to the client and if it differs we send the client an update asynchronously, otherwise we add the client to the waiting list:</p> <pre><code> if(last_id != counter_) { async_send(context); } else waiters_.insert(context); } </code></pre> <p>The code that sends the request to the client is quite simple, we send the last price id - simple counter that would use us for synchronization in case of disconnect and send an actual data.</p> <pre><code>void async_send(booster::shared_ptr&lt;cppcms::http::context&gt; waiter) { waiter-&gt;response().out() &lt;&lt; "id:" &lt;&lt; counter_ &lt;&lt;"\n" "data:" &lt;&lt; price_ &lt;&lt; "\n" "\n"; </code></pre> <p>Then we setup a completion callback, if the operation fails (client had disconnected), we just exit, and the context would be automatically destroyed.</p> <pre><code> waiter-&gt;async_flush_output([=,counter_](cppcms::http::context::completion_type status){ if(status!=0) return; </code></pre> <p>Otherwise we check if there were an updates since the data was sent, and if yes we send the latest price once again, otherwise we add the client to the waiting list.</p> <pre><code> if(counter_ != this-&gt;counter_) { this-&gt;async_send(waiter); } else { this-&gt;waiters_.insert(waiter); } }); </code></pre> <p>This completes our function.</p> <pre><code>} </code></pre> <p>Note: that our lambda expression captures the <code>waiter</code> variable and keeps it alive till the handler is executed.</p> <p>Now the last and the simplest thing - updating the price. Upon price update, we increase the identification counter and notify all objects in the waiting list.</p> <pre><code>void update_price(double new_one) { counter_++; price_ = new_one; for(auto waiter : waiters_) { async_send(waiter); } </code></pre> <p>Afterwards we clear the list - now the callback object owns the context and would destroy it in case of an error.</p> <pre><code> waiters_.clear(); } </code></pre> <p>The full code of the sample including simple timer based random price generation can be found <a href="http://cppcms.com/files/ticker/">there</a>.</p> <h3>Falling Back to Long Polling</h3> <p>Is very simple. We would use the same protocol, but when the event is ready we would close the connection. In order to let the server to distinguish between EventSource and XHR long polling we would add a special header like <code>X-Event-Source-Simulate: Long-Polling</code></p> <p>Then we would change a little our <code>async_send</code> function by adding the following lines:</p> <pre><code> if(waiter-&gt;request().getenv("HTTP_X_EVENT_SOURCE_SIMULATE")=="Long-Polling") { waiter-&gt;async_complete_response(); return; } </code></pre> <p>Such that our function would look like:</p> <pre><code> waiter-&gt;response().out() &lt;&lt; "id:" &lt;&lt; counter_ &lt;&lt;"\n" "data:" &lt;&lt; price_ &lt;&lt; "\n" "\n"; if(waiter-&gt;request().getenv("HTTP_X_EVENT_SOURCE_SIMULATE")=="Long-Polling") { waiter-&gt;async_complete_response(); return; } waiter-&gt;async_flush_output(...) ... </code></pre> <p>Of course XHR simulation would have to send and manage <code>Last-Event-Id</code> header and parse the response, but the server side would look almost identically.</p> <h3>Connecting to the web server</h3> <p>When it is coming to configuring a web server you should make sure that it does not buffer out-coming request and sends them immediately to the client:</p> <ul> <li>Lighttpd does this by default for FastCGI, SCGI and HTTP protocols.</li> <li>Apache does this by default for SCGI and HTTP, but for FastCGI (mod_fastcgi) it requires <code>-flush</code> option to work correctly.</li> </ul> <p>Now once again Nginx shows us its problems:</p> <ul> <li>SCGI requires option <code>scgi_buffering off</code></li> <li>HTTP requires option <code>http_buffering off</code></li> </ul> <p>However, FastCGI does not implement such an option! <a href="http://trac.nginx.org/nginx/ticket/159">See this ticket</a></p> <p>So don't even try to use Nginx with FastCGI for Server-Sent Events.</p> <p>Once again, give yourself a favor, <a href="http://blog.cppcms.com/post/99">use lighttpd</a></p> <h3>Thanks</h3> <p>Special thanks to Barbu Paul - Gheorghe,that had brought to my attention such a powerful and useful HTML5 feature.</p> </div> Slides From Lecture about CppCMS http://blog.cppcms.com/post/108 http://blog.cppcms.com/post/108 <div style="direction:ltr"> <p>At August 3rd, I had given a lecture about CppCMS at the annual Israeli FOSS conference <a href="http://august.penguin.org.il/">August Penguin</a>.</p> <p>The slides are now available for download:</p> <p><a href="http://cppcms.com/files/ap2012/">http://cppcms.com/files/ap2012/</a></p> </div> CppDB 0.3.1 Released http://blog.cppcms.com/post/106 http://blog.cppcms.com/post/106 <div style="direction:ltr"> <p>This is an important bugfix release.</p> <p>It is recommended for all users to upgrade to latest version:</p> <p>Critical Bugs fixed:</p> <ul> <li>Fixed bug #3536452: <ul> <li><code>cppdb::transaction::~transaction()</code> could leak an exception</li> <li><code>busy_timeout</code> option was not working for sqlite3 backend</li> </ul> </li> <li>Fixed incorrect use of <code>SQLITE_STATIC</code> that could cause crash</li> </ul> <p>Full Changelog: <a href="http://cppcms.com/sql/cppdb_0.3.1/changelog.html">http://cppcms.com/sql/cppdb_0.3.1/changelog.html</a><br/> Downloads: <a href="https://sourceforge.net/projects/cppcms/files/cppdb/">https://sourceforge.net/projects/cppcms/files/cppdb/</a></p> </div> How not to do Unicode... http://blog.cppcms.com/post/105 http://blog.cppcms.com/post/105 <div style="direction:ltr"> <p>All started from a small problem, how to print Unicode text to the Windows Console with option redirect to a file.</p> <p>Let's say we have a program Hello that prints few words in several languages to the screen..</p> <pre><code>#include &lt;stdio.h&gt; int main() { printf("Мир Peace Ειρήνη\n"); return 0; } </code></pre> <p>The program above is trivial and works fine under Windows if current console codepage is set to UTF-8. Also this can be fixed from the program by calling <code>SetConsolseOutputCP(CP_UTF8)</code>.</p> <p>Now simple tweak... Instead of that standard C <code>printf</code> we would use standard C++ <code>std::cout</code>... It works fine for GCC. But under Visual C++ it prints squares...</p> <p>If I try redirection <code>test.exe &gt;test.txt</code> - I get perfectly fine UTF-8 text...</p> <p>I had started researching the issue and found the <a href="http://blogs.msdn.com/b/michkap/archive/2008/03/18/8306597.aspx">post</a> of one of the Windows Unicode Gurus <a href="http://blogs.msdn.com/b/michkap/">Michael Kaplan's</a>.</p> <p>I've tried to run <code>_setmode(_fileno(stdout), _O_U8TEXT)</code> as recommended by the Microsoft's Unicode guru and... By program crashed on attempt to write to the output stream.</p> <p>Keeping searching for an answer I've got to this <a href="http://connect.microsoft.com/VisualStudio/feedback/details/431244/std-ostream-fails-to-write-utf-8-encoded-string-to-console">bug report</a>...</p> <p>Short summary:</p> <ul> <li>User: Can't print UTF-8 to console with std::cout</li> <li>MS: Closing - this is by design, see Michael Kaplan's article about writing to console</li> <li>User: But if I do what suggested program crashes, and I still can't write Unicode to console</li> <li>MS: Reactivate the ticket if it does not works</li> <li>User: it does not!</li> <li>MS: Use wide output...</li> <li>User: I'd rather use fprintf in first place!?</li> </ul> <p>To the summary...</p> <p>If you use Visual C++ you can't use UTF-8 to print text to <code>std::cout</code>.</p> <p>If you still want to, please read this <a href="http://alfps.wordpress.com/2011/12/08/unicode-part-2-utf-8-stream-mode/">amazingly long article</a> about how to make <code>wcout</code> and <code>cout</code> working, but it does not really give a simple solution - finally falling to redefinition of the stream buffers...</p> <p>So please, if you design API or Operating System, <strong>do not use</strong> kind of "Wide" API... This is is the wrong way to do Unicode.</p> <p>Which reminds me... Spread around:</p> <p><a href="http://www.utf8everywhere.org/">http://www.utf8everywhere.org/</a></p> <p>Related Posts: <a href="http://blog.cppcms.com/post/62">http://blog.cppcms.com/post/62</a></p> </div>