2011-11-15 16:44:47 +04:00
|
|
|
/*
|
|
|
|
This file is part of the PhantomJS project from Ofi Labs.
|
|
|
|
|
|
|
|
Copyright (C) 2011 Klarälvdalens Datakonsult AB, a KDAB Group company, info@kdab.com
|
|
|
|
Author: Milian Wolff <milian.wolff@kdab.com>
|
|
|
|
|
|
|
|
Redistribution and use in source and binary forms, with or without
|
|
|
|
modification, are permitted provided that the following conditions are met:
|
|
|
|
|
|
|
|
* Redistributions of source code must retain the above copyright
|
|
|
|
notice, this list of conditions and the following disclaimer.
|
|
|
|
* Redistributions in binary form must reproduce the above copyright
|
|
|
|
notice, this list of conditions and the following disclaimer in the
|
|
|
|
documentation and/or other materials provided with the distribution.
|
|
|
|
* Neither the name of the <organization> nor the
|
|
|
|
names of its contributors may be used to endorse or promote products
|
|
|
|
derived from this software without specific prior written permission.
|
|
|
|
|
|
|
|
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
|
|
|
|
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
ARE DISCLAIMED. IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY
|
|
|
|
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
|
|
|
|
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
|
|
|
|
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
|
|
|
|
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
|
|
|
|
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "webserver.h"
|
|
|
|
|
2012-02-10 22:42:38 +04:00
|
|
|
#include "mongoose/mongoose.h"
|
2011-12-20 20:24:08 +04:00
|
|
|
|
2011-12-20 06:18:08 +04:00
|
|
|
#include <QByteArray>
|
2011-11-07 19:16:54 +04:00
|
|
|
#include <QHostAddress>
|
2011-12-05 10:34:44 +04:00
|
|
|
#include <QMetaType>
|
2011-12-20 20:24:08 +04:00
|
|
|
#include <QThread>
|
2011-12-20 06:18:08 +04:00
|
|
|
#include <QUrl>
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
#include <QVector>
|
|
|
|
|
|
|
|
namespace UrlEncodedParser {
|
|
|
|
|
|
|
|
QString unescape(QByteArray in)
|
|
|
|
{
|
|
|
|
// first step: decode '+' to spaces
|
|
|
|
for(int i = 0; i < in.length(); ++i) {
|
|
|
|
QByteRef c = in[i];
|
|
|
|
if (c == '+') {
|
|
|
|
c = ' ';
|
|
|
|
}
|
|
|
|
}
|
|
|
|
// now decode as usual
|
|
|
|
return QUrl::fromPercentEncoding(in);
|
|
|
|
};
|
|
|
|
|
|
|
|
// Parse a application/x-www-form-urlencoded data string
|
|
|
|
QVariantMap parse(const QByteArray &data) {
|
|
|
|
QVariantMap ret;
|
|
|
|
if (data.isEmpty()) {
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
foreach(const QByteArray &part, data.split('&')) {
|
|
|
|
const int eqPos = part.indexOf('=');
|
|
|
|
if (eqPos == -1) {
|
|
|
|
ret[unescape(part)] = "";
|
|
|
|
} else {
|
|
|
|
const QByteArray key = part.mid(0, eqPos);
|
|
|
|
const QByteArray value = part.mid(eqPos + 1);
|
|
|
|
ret[unescape(key)] = unescape(value);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
2011-11-15 16:44:47 +04:00
|
|
|
|
|
|
|
static void *callback(mg_event event,
|
|
|
|
mg_connection *conn,
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
const mg_request_info *request)
|
2011-11-15 16:44:47 +04:00
|
|
|
{
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
WebServer* server = static_cast<WebServer*>(request->user_data);
|
|
|
|
if (server->handleRequest(event, conn, request)) {
|
2011-11-15 16:44:47 +04:00
|
|
|
// anything non-null... pretty ugly, why not simply a bool??
|
|
|
|
return server;
|
|
|
|
} else {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-01-04 21:06:55 +04:00
|
|
|
WebServer::WebServer(QObject *parent, Config *config)
|
A REPL for PhantomJS
This covers [Issue 252](http://code.google.com/p/phantomjs/issues/detail?id=252)
The commit is composed of 12 squashed commits:
commit efdc6ba4f143c30a690fd97d92d80fa412e79999
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Mon Feb 27 00:19:36 2012 +0000
Pretty-pringing and Completion Caching done!
* This completes pretty-printing for the result of evaluated
* expressions in the REPL.
* Also, now we cache the "possible completions", to speed things up
* a bit (nothing fancy though).
* Minor tweaks to the internal doc and the way we "mock"
* pretty-printing for QObjects/REPLCompletanle
* All tests passing :)
commit 1f9ef690e112a535b431fca409b77bb9c09d1c70
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Sun Feb 26 22:35:00 2012 +0000
Moving most of REPL shim JavaScritp code in a separate file. Way
easier to work on.
commit 02d460a16fee14e7096ae7d899c03902c5b8a9c6
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Sat Feb 25 20:25:18 2012 +0000
Initialisation of the Completions is now done in a pure virtual.
This means that every REPLCompletable object will ACTUALLY register
completion strings, ONLY if we are running a REPL
and that object is ACTUALLY created.
Otherwise, why bother?
Adding completions for all exposed REPLCompletable objects
Also, fixed an issue with _getCompletions()
commit 412c3778fb04aa1c7379f8e760afce702b0428dd
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Tue Feb 21 00:49:17 2012 +0000
Few more tweaks to the REPL:
- Now 'phantom' is the first QObject with proper completion
- No repetition in QObject completions
- LVAL of any user expression is now correctly prettified and
printed
Major things left to do:
- Cache completions (using QCache?)
- Add completions for the other QObject
- When the LVAL of a user expression is a QObject, print what's
expected, not the QObject "real" structure
commit 46f04713c8165d898055e15478bb31403f8c93f1
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Tue Feb 7 10:13:23 2012 -0800
Pretty-print expressions result
Still not done though: there are issues with the NON-Native JS
objects.
commit 98b2fe67651dc750b62c6fa9cf1d80317fd9ae06
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Fri Feb 3 00:22:52 2012 -0800
Introducing REPLCompletable.
This class should be inherited by any JavaScript-exposed QObject, to
ensure correct Auto-Completion.
Correct auto-completion for QObjects.
- Now even QObjects can correctly provide auto-completion, and avoid
showing "not for users" methods
- The strings used for the auto-completion are stored in a single
Index: minimum memory footprint
- Still, there is optimization that should be done (when "searching"
for the right completion by prefix)
- Completion for the objects not set up yet, but now it's just a
trivial sequence of "addCompletion('bla')" in their constructors
commit 9bd48618154b1530a37b41f4060440184e23253d
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Thu Feb 2 00:20:25 2012 -0800
Changing the way we import Linenoise.
Will just import a specific commit, and update manually when needed.
commit cfc9bae9fbdab13b01019b34b7cbd565e3153780
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Sun Jan 29 23:22:26 2012 -0800
Made the REPL into a Singleton. With Auto-completion!.
Reasons:
1) Needed a pointer to function (i.e. a static method) to be used
with Linenoise to provide auto-completions
2) It makes more sense, as it's not like we are going to have 2 REPL
running at the same time, are we?
There are problems to address:
- the enumeration in JS seems to return only the native interface of
our objects
- the function completions contain argument types of those functions
- "private" methods are exposed
commit c78bd32e17f8e0e4cc4a0066858de8cc81d33b97
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Sun Jan 29 22:10:20 2012 -0800
Migrating from the original, now [unmantained
Linenoise](https://github.com/antirez/linenoise) to the fairly active
[tadmarshall fork](https://github.com/tadmarshall/linenoise).
Also now the project is imported as a Git Submodule.
Having migrated to the latest Linenoise (see prev. commit), now this
_SHOULD_ work on Windows too.
But, of course, this needs testing. :)
commit 43713c5723d7c5ed446ba41ae8d6f8c9feba7f9b
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Tue Jan 24 23:17:06 2012 -0800
Now that the basics work, I'm adding support for REPL history.
This is something almost everyone today is accustomed to.
Also, now REPL history works!
And I found some useful resources to solve pending TODOs.
commit 31e5f88b044a5b4a823c67527ef8c245d2ac7863
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Sun Jan 22 20:56:36 2012 -0800
Adding Linenoise Project (https://github.com/antirez/linenoise).
For now is included as a drop-in set of files.
Later on, if the Linenoise project has frequent
updates, we might prefer to do it as a
git-submodule.
commit 4be9c15c65db4767e482fba0be13f8aab286d5f3
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Thu Jan 5 15:31:13 2012 +0000
First simple REPL implementation.
- Not complete
- Still doesn't handle arrow keys (needed for history)
2012-01-05 19:31:13 +04:00
|
|
|
: REPLCompletable(parent)
|
2012-01-04 20:54:38 +04:00
|
|
|
, m_config(config)
|
2011-11-15 16:44:47 +04:00
|
|
|
, m_ctx(0)
|
|
|
|
{
|
2011-11-07 21:25:57 +04:00
|
|
|
setObjectName("WebServer");
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
qRegisterMetaType<WebServerResponse*>("WebServerResponse*");
|
2011-11-15 16:44:47 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
WebServer::~WebServer()
|
|
|
|
{
|
2011-11-07 21:24:45 +04:00
|
|
|
close();
|
2011-11-15 16:44:47 +04:00
|
|
|
}
|
|
|
|
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
bool WebServer::listenOnPort(const QString& port, const QVariantMap& opts)
|
2011-11-15 16:44:47 +04:00
|
|
|
{
|
2011-11-07 21:24:45 +04:00
|
|
|
///TODO: listen on multiple ports?
|
|
|
|
close();
|
|
|
|
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
QVector<const char*> options;
|
|
|
|
options << "listening_ports" << qstrdup(qPrintable(port));
|
|
|
|
options << "enable_directory_listing" << "no";
|
2012-03-14 21:51:35 +04:00
|
|
|
if (opts.value("keepAlive", false).toBool()) {
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
options << "enable_keep_alive" << "yes";
|
|
|
|
}
|
|
|
|
options << NULL;
|
2011-11-15 16:44:47 +04:00
|
|
|
///TODO: more options from m_config?
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
m_ctx = mg_start(&callback, this, options.data());
|
2011-11-15 16:44:47 +04:00
|
|
|
if (!m_ctx) {
|
2011-11-07 21:35:35 +04:00
|
|
|
return false;
|
2011-11-15 16:44:47 +04:00
|
|
|
}
|
2011-11-07 21:35:35 +04:00
|
|
|
|
|
|
|
m_port = port;
|
|
|
|
return true;
|
2011-11-15 16:44:47 +04:00
|
|
|
}
|
|
|
|
|
2011-11-07 21:24:45 +04:00
|
|
|
QString WebServer::port() const
|
|
|
|
{
|
|
|
|
return m_port;
|
|
|
|
}
|
|
|
|
|
|
|
|
void WebServer::close()
|
|
|
|
{
|
|
|
|
if (m_ctx) {
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
m_closing = 1;
|
|
|
|
{
|
|
|
|
// make sure we wake up all pending responses, such that mg_stop()
|
|
|
|
// can be called without deadlocking
|
|
|
|
QMutexLocker lock(&m_mutex);
|
2012-03-14 18:45:53 +04:00
|
|
|
foreach(WebServerResponse* response, m_pendingResponses) {
|
|
|
|
response->close();
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
}
|
|
|
|
}
|
2011-11-07 21:24:45 +04:00
|
|
|
mg_stop(m_ctx);
|
|
|
|
m_ctx = 0;
|
|
|
|
m_port.clear();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
bool WebServer::handleRequest(mg_event event, mg_connection *conn, const mg_request_info *request)
|
2012-02-15 16:52:57 +04:00
|
|
|
{
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
if (event != MG_NEW_REQUEST) {
|
|
|
|
return false;
|
2012-02-15 16:52:57 +04:00
|
|
|
}
|
|
|
|
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
if (m_closing) {
|
|
|
|
return false;
|
2012-02-15 16:52:57 +04:00
|
|
|
}
|
|
|
|
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
// Modelled after http://nodejs.org/docs/latest/api/http.html#http.ServerRequest
|
|
|
|
QVariantMap requestObject;
|
2011-12-20 06:18:08 +04:00
|
|
|
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
///TODO: encoding?!
|
2011-12-20 06:18:08 +04:00
|
|
|
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
if (request->request_method)
|
|
|
|
requestObject["method"] = QString::fromLocal8Bit(request->request_method);
|
|
|
|
if (request->http_version)
|
|
|
|
requestObject["httpVersion"] = QString::fromLocal8Bit(request->http_version);
|
|
|
|
if (request->status_code >=0)
|
|
|
|
requestObject["statusCode"] = request->status_code;
|
2011-12-20 06:18:08 +04:00
|
|
|
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
QByteArray uri(request->uri);
|
|
|
|
if (uri.startsWith('/'))
|
2012-03-20 17:50:53 +04:00
|
|
|
uri = '/' + QUrl::toPercentEncoding(QString::fromLatin1(request->uri + 1), "/?&#");
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
if (request->query_string)
|
|
|
|
uri.append('?').append(QByteArray(request->query_string));
|
|
|
|
requestObject["url"] = uri.data();
|
2011-12-20 06:18:08 +04:00
|
|
|
|
|
|
|
#if 0
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
// Non-standard and thus disable for the time being.
|
|
|
|
requestObject["isSSL"] = request->is_ssl;
|
|
|
|
requestObject["remoteIP"] = QHostAddress(request->remote_ip).toString();;
|
|
|
|
requestObject["remotePort"] = request->remote_port;
|
|
|
|
if (request->remote_user)
|
|
|
|
requestObject["remoteUser"] = QString::fromLocal8Bit(request->remote_user);
|
2011-12-20 06:18:08 +04:00
|
|
|
#endif
|
|
|
|
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
QVariantMap headersObject;
|
|
|
|
for (int i = 0; i < request->num_headers; ++i) {
|
|
|
|
QString key = QString::fromLocal8Bit(request->http_headers[i].name);
|
|
|
|
QString value = QString::fromLocal8Bit(request->http_headers[i].value);
|
|
|
|
headersObject[key] = value;
|
|
|
|
}
|
|
|
|
requestObject["headers"] = headersObject;
|
|
|
|
|
|
|
|
if ((requestObject["method"] == "POST" || requestObject["method"] == "PUT")
|
|
|
|
&& headersObject.contains("Content-Length"))
|
|
|
|
{
|
|
|
|
bool ok = false;
|
|
|
|
uint contentLength = headersObject["Content-Length"].toUInt(&ok);
|
|
|
|
if (ok) {
|
|
|
|
contentLength += 1; // allow \0 at end
|
|
|
|
char * data = new char[contentLength];
|
|
|
|
int read = mg_read(conn, data, contentLength);
|
|
|
|
QByteArray rawData(data, read);
|
|
|
|
requestObject["rawData"] = rawData;
|
|
|
|
if (headersObject["Content-Type"] == "application/x-www-form-urlencoded") {
|
|
|
|
requestObject["post"] = UrlEncodedParser::parse(rawData);
|
|
|
|
}
|
|
|
|
delete[] data;
|
2011-12-20 06:18:08 +04:00
|
|
|
}
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
}
|
2011-12-20 06:18:08 +04:00
|
|
|
|
2012-03-14 18:45:53 +04:00
|
|
|
// Emit signal that is catched by the PhantomJS callback,
|
|
|
|
// then wait until response.close() was called from
|
|
|
|
// the PhantomJS script.
|
|
|
|
//
|
|
|
|
// This is achieved using the wait semaphore, which is
|
|
|
|
// acquired here, in the background thread, and released
|
|
|
|
// in WebServerResponse::close() i.e. the foreground thread
|
|
|
|
QSemaphore wait;
|
|
|
|
WebServerResponse responseObject(conn, &wait);
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
responseObject.moveToThread(thread());
|
|
|
|
|
|
|
|
{
|
|
|
|
if (m_closing) {
|
|
|
|
return false;
|
2012-02-15 16:52:57 +04:00
|
|
|
}
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
QMutexLocker lock(&m_mutex);
|
|
|
|
if (m_closing) {
|
|
|
|
return false;
|
|
|
|
}
|
2012-03-14 18:45:53 +04:00
|
|
|
m_pendingResponses << (&responseObject);
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
}
|
2012-03-14 18:45:53 +04:00
|
|
|
newRequest(requestObject, &responseObject);
|
|
|
|
wait.acquire();
|
|
|
|
{
|
|
|
|
if (m_closing) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
QMutexLocker lock(&m_mutex);
|
|
|
|
if (m_closing) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
m_pendingResponses.removeOne(&responseObject);
|
support keep-alive in the webserver
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0a56874daba39c7d69f64e3d64c2eb8,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
2012-03-06 16:33:56 +04:00
|
|
|
}
|
2012-03-14 18:45:53 +04:00
|
|
|
return true;
|
2011-11-15 16:44:47 +04:00
|
|
|
}
|
2011-11-05 19:38:08 +04:00
|
|
|
|
A REPL for PhantomJS
This covers [Issue 252](http://code.google.com/p/phantomjs/issues/detail?id=252)
The commit is composed of 12 squashed commits:
commit efdc6ba4f143c30a690fd97d92d80fa412e79999
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Mon Feb 27 00:19:36 2012 +0000
Pretty-pringing and Completion Caching done!
* This completes pretty-printing for the result of evaluated
* expressions in the REPL.
* Also, now we cache the "possible completions", to speed things up
* a bit (nothing fancy though).
* Minor tweaks to the internal doc and the way we "mock"
* pretty-printing for QObjects/REPLCompletanle
* All tests passing :)
commit 1f9ef690e112a535b431fca409b77bb9c09d1c70
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Sun Feb 26 22:35:00 2012 +0000
Moving most of REPL shim JavaScritp code in a separate file. Way
easier to work on.
commit 02d460a16fee14e7096ae7d899c03902c5b8a9c6
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Sat Feb 25 20:25:18 2012 +0000
Initialisation of the Completions is now done in a pure virtual.
This means that every REPLCompletable object will ACTUALLY register
completion strings, ONLY if we are running a REPL
and that object is ACTUALLY created.
Otherwise, why bother?
Adding completions for all exposed REPLCompletable objects
Also, fixed an issue with _getCompletions()
commit 412c3778fb04aa1c7379f8e760afce702b0428dd
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Tue Feb 21 00:49:17 2012 +0000
Few more tweaks to the REPL:
- Now 'phantom' is the first QObject with proper completion
- No repetition in QObject completions
- LVAL of any user expression is now correctly prettified and
printed
Major things left to do:
- Cache completions (using QCache?)
- Add completions for the other QObject
- When the LVAL of a user expression is a QObject, print what's
expected, not the QObject "real" structure
commit 46f04713c8165d898055e15478bb31403f8c93f1
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Tue Feb 7 10:13:23 2012 -0800
Pretty-print expressions result
Still not done though: there are issues with the NON-Native JS
objects.
commit 98b2fe67651dc750b62c6fa9cf1d80317fd9ae06
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Fri Feb 3 00:22:52 2012 -0800
Introducing REPLCompletable.
This class should be inherited by any JavaScript-exposed QObject, to
ensure correct Auto-Completion.
Correct auto-completion for QObjects.
- Now even QObjects can correctly provide auto-completion, and avoid
showing "not for users" methods
- The strings used for the auto-completion are stored in a single
Index: minimum memory footprint
- Still, there is optimization that should be done (when "searching"
for the right completion by prefix)
- Completion for the objects not set up yet, but now it's just a
trivial sequence of "addCompletion('bla')" in their constructors
commit 9bd48618154b1530a37b41f4060440184e23253d
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Thu Feb 2 00:20:25 2012 -0800
Changing the way we import Linenoise.
Will just import a specific commit, and update manually when needed.
commit cfc9bae9fbdab13b01019b34b7cbd565e3153780
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Sun Jan 29 23:22:26 2012 -0800
Made the REPL into a Singleton. With Auto-completion!.
Reasons:
1) Needed a pointer to function (i.e. a static method) to be used
with Linenoise to provide auto-completions
2) It makes more sense, as it's not like we are going to have 2 REPL
running at the same time, are we?
There are problems to address:
- the enumeration in JS seems to return only the native interface of
our objects
- the function completions contain argument types of those functions
- "private" methods are exposed
commit c78bd32e17f8e0e4cc4a0066858de8cc81d33b97
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Sun Jan 29 22:10:20 2012 -0800
Migrating from the original, now [unmantained
Linenoise](https://github.com/antirez/linenoise) to the fairly active
[tadmarshall fork](https://github.com/tadmarshall/linenoise).
Also now the project is imported as a Git Submodule.
Having migrated to the latest Linenoise (see prev. commit), now this
_SHOULD_ work on Windows too.
But, of course, this needs testing. :)
commit 43713c5723d7c5ed446ba41ae8d6f8c9feba7f9b
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Tue Jan 24 23:17:06 2012 -0800
Now that the basics work, I'm adding support for REPL history.
This is something almost everyone today is accustomed to.
Also, now REPL history works!
And I found some useful resources to solve pending TODOs.
commit 31e5f88b044a5b4a823c67527ef8c245d2ac7863
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Sun Jan 22 20:56:36 2012 -0800
Adding Linenoise Project (https://github.com/antirez/linenoise).
For now is included as a drop-in set of files.
Later on, if the Linenoise project has frequent
updates, we might prefer to do it as a
git-submodule.
commit 4be9c15c65db4767e482fba0be13f8aab286d5f3
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Thu Jan 5 15:31:13 2012 +0000
First simple REPL implementation.
- Not complete
- Still doesn't handle arrow keys (needed for history)
2012-01-05 19:31:13 +04:00
|
|
|
void WebServer::initCompletions()
|
|
|
|
{
|
|
|
|
// Add completion for the Dynamic Properties of the 'webpage' object
|
|
|
|
// properties
|
|
|
|
addCompletion("clipRect");
|
|
|
|
// functions
|
|
|
|
addCompletion("listen");
|
|
|
|
addCompletion("close");
|
|
|
|
// callbacks
|
|
|
|
addCompletion("onNewRequest");
|
|
|
|
}
|
|
|
|
|
2011-11-05 19:38:08 +04:00
|
|
|
|
|
|
|
//BEGIN WebServerResponse
|
|
|
|
|
2012-03-14 18:45:53 +04:00
|
|
|
WebServerResponse::WebServerResponse(mg_connection* conn, QSemaphore* close)
|
A REPL for PhantomJS
This covers [Issue 252](http://code.google.com/p/phantomjs/issues/detail?id=252)
The commit is composed of 12 squashed commits:
commit efdc6ba4f143c30a690fd97d92d80fa412e79999
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Mon Feb 27 00:19:36 2012 +0000
Pretty-pringing and Completion Caching done!
* This completes pretty-printing for the result of evaluated
* expressions in the REPL.
* Also, now we cache the "possible completions", to speed things up
* a bit (nothing fancy though).
* Minor tweaks to the internal doc and the way we "mock"
* pretty-printing for QObjects/REPLCompletanle
* All tests passing :)
commit 1f9ef690e112a535b431fca409b77bb9c09d1c70
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Sun Feb 26 22:35:00 2012 +0000
Moving most of REPL shim JavaScritp code in a separate file. Way
easier to work on.
commit 02d460a16fee14e7096ae7d899c03902c5b8a9c6
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Sat Feb 25 20:25:18 2012 +0000
Initialisation of the Completions is now done in a pure virtual.
This means that every REPLCompletable object will ACTUALLY register
completion strings, ONLY if we are running a REPL
and that object is ACTUALLY created.
Otherwise, why bother?
Adding completions for all exposed REPLCompletable objects
Also, fixed an issue with _getCompletions()
commit 412c3778fb04aa1c7379f8e760afce702b0428dd
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Tue Feb 21 00:49:17 2012 +0000
Few more tweaks to the REPL:
- Now 'phantom' is the first QObject with proper completion
- No repetition in QObject completions
- LVAL of any user expression is now correctly prettified and
printed
Major things left to do:
- Cache completions (using QCache?)
- Add completions for the other QObject
- When the LVAL of a user expression is a QObject, print what's
expected, not the QObject "real" structure
commit 46f04713c8165d898055e15478bb31403f8c93f1
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Tue Feb 7 10:13:23 2012 -0800
Pretty-print expressions result
Still not done though: there are issues with the NON-Native JS
objects.
commit 98b2fe67651dc750b62c6fa9cf1d80317fd9ae06
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Fri Feb 3 00:22:52 2012 -0800
Introducing REPLCompletable.
This class should be inherited by any JavaScript-exposed QObject, to
ensure correct Auto-Completion.
Correct auto-completion for QObjects.
- Now even QObjects can correctly provide auto-completion, and avoid
showing "not for users" methods
- The strings used for the auto-completion are stored in a single
Index: minimum memory footprint
- Still, there is optimization that should be done (when "searching"
for the right completion by prefix)
- Completion for the objects not set up yet, but now it's just a
trivial sequence of "addCompletion('bla')" in their constructors
commit 9bd48618154b1530a37b41f4060440184e23253d
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Thu Feb 2 00:20:25 2012 -0800
Changing the way we import Linenoise.
Will just import a specific commit, and update manually when needed.
commit cfc9bae9fbdab13b01019b34b7cbd565e3153780
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Sun Jan 29 23:22:26 2012 -0800
Made the REPL into a Singleton. With Auto-completion!.
Reasons:
1) Needed a pointer to function (i.e. a static method) to be used
with Linenoise to provide auto-completions
2) It makes more sense, as it's not like we are going to have 2 REPL
running at the same time, are we?
There are problems to address:
- the enumeration in JS seems to return only the native interface of
our objects
- the function completions contain argument types of those functions
- "private" methods are exposed
commit c78bd32e17f8e0e4cc4a0066858de8cc81d33b97
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Sun Jan 29 22:10:20 2012 -0800
Migrating from the original, now [unmantained
Linenoise](https://github.com/antirez/linenoise) to the fairly active
[tadmarshall fork](https://github.com/tadmarshall/linenoise).
Also now the project is imported as a Git Submodule.
Having migrated to the latest Linenoise (see prev. commit), now this
_SHOULD_ work on Windows too.
But, of course, this needs testing. :)
commit 43713c5723d7c5ed446ba41ae8d6f8c9feba7f9b
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Tue Jan 24 23:17:06 2012 -0800
Now that the basics work, I'm adding support for REPL history.
This is something almost everyone today is accustomed to.
Also, now REPL history works!
And I found some useful resources to solve pending TODOs.
commit 31e5f88b044a5b4a823c67527ef8c245d2ac7863
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Sun Jan 22 20:56:36 2012 -0800
Adding Linenoise Project (https://github.com/antirez/linenoise).
For now is included as a drop-in set of files.
Later on, if the Linenoise project has frequent
updates, we might prefer to do it as a
git-submodule.
commit 4be9c15c65db4767e482fba0be13f8aab286d5f3
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Thu Jan 5 15:31:13 2012 +0000
First simple REPL implementation.
- Not complete
- Still doesn't handle arrow keys (needed for history)
2012-01-05 19:31:13 +04:00
|
|
|
: REPLCompletable()
|
2012-02-10 22:42:38 +04:00
|
|
|
, m_conn(conn)
|
2011-11-07 20:33:35 +04:00
|
|
|
, m_statusCode(200)
|
|
|
|
, m_headersSent(false)
|
2012-03-14 18:45:53 +04:00
|
|
|
, m_close(close)
|
2011-11-05 19:38:08 +04:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2011-11-07 20:33:35 +04:00
|
|
|
const char* responseCodeString(int code)
|
2011-11-05 19:38:08 +04:00
|
|
|
{
|
2011-11-07 20:33:35 +04:00
|
|
|
// see: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
|
|
|
|
switch (code) {
|
|
|
|
case 100:
|
|
|
|
return "Continue";
|
|
|
|
case 101:
|
|
|
|
return "Switching Protocols";
|
|
|
|
case 200:
|
|
|
|
return "OK";
|
|
|
|
case 201:
|
|
|
|
return "Created";
|
|
|
|
case 202:
|
|
|
|
return "Accepted";
|
|
|
|
case 203:
|
|
|
|
return "Non-Authoritative Information";
|
|
|
|
case 204:
|
|
|
|
return "No Content";
|
|
|
|
case 205:
|
|
|
|
return "Reset Content";
|
|
|
|
case 206:
|
|
|
|
return "Partial Content";
|
|
|
|
case 300:
|
|
|
|
return "Multiple Choices";
|
|
|
|
case 301:
|
|
|
|
return "Moved Permanently";
|
|
|
|
case 302:
|
|
|
|
return "Found";
|
|
|
|
case 303:
|
|
|
|
return "See Other";
|
|
|
|
case 304:
|
|
|
|
return "Not Modified";
|
|
|
|
case 305:
|
|
|
|
return "Use Proxy";
|
|
|
|
case 307:
|
|
|
|
return "Temporary Redirect";
|
|
|
|
case 400:
|
|
|
|
return "Bad Request";
|
|
|
|
case 401:
|
|
|
|
return "Unauthorized";
|
|
|
|
case 402:
|
|
|
|
return "Payment Required";
|
|
|
|
case 403:
|
|
|
|
return "Forbidden";
|
|
|
|
case 404:
|
|
|
|
return "Not Found";
|
|
|
|
case 405:
|
|
|
|
return "Method Not Allowed";
|
|
|
|
case 406:
|
|
|
|
return "Not Acceptable";
|
|
|
|
case 407:
|
|
|
|
return "Proxy Authentication Required";
|
|
|
|
case 408:
|
|
|
|
return "Request Timeout";
|
|
|
|
case 409:
|
|
|
|
return "Conflict";
|
|
|
|
case 410:
|
|
|
|
return "Gone";
|
|
|
|
case 411:
|
|
|
|
return "Length Required";
|
|
|
|
case 412:
|
|
|
|
return "Precondition Failed";
|
|
|
|
case 413:
|
|
|
|
return "Request Entity Too Large";
|
|
|
|
case 414:
|
|
|
|
return "Request-URI Too Long";
|
|
|
|
case 415:
|
|
|
|
return "Unsupported Media Type";
|
|
|
|
case 416:
|
|
|
|
return "Requested Range not Satisfiable";
|
|
|
|
case 417:
|
|
|
|
return "Expectation Failed";
|
|
|
|
case 500:
|
|
|
|
return "Internal Server Error";
|
|
|
|
case 501:
|
|
|
|
return "Not Implemented";
|
|
|
|
case 502:
|
|
|
|
return "Bad Gateway";
|
|
|
|
case 503:
|
|
|
|
return "Service Unavailable";
|
|
|
|
case 504:
|
|
|
|
return "Gateway Timeout";
|
|
|
|
case 505:
|
|
|
|
return "HTTP Version Not Supported";
|
|
|
|
case 306:
|
|
|
|
// unused: fallthrough
|
|
|
|
default:
|
|
|
|
return "";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-12-20 06:18:08 +04:00
|
|
|
void WebServerResponse::writeHead(int statusCode, const QVariantMap &headers)
|
2011-11-07 20:33:35 +04:00
|
|
|
{
|
|
|
|
///TODO: what is the best-practice error handling in javascript? exceptions?
|
|
|
|
Q_ASSERT(!m_headersSent);
|
|
|
|
m_headersSent = true;
|
2011-12-21 19:49:00 +04:00
|
|
|
m_statusCode = statusCode;
|
2011-11-07 20:33:35 +04:00
|
|
|
mg_printf(m_conn, "HTTP/1.1 %d %s\r\n", m_statusCode, responseCodeString(m_statusCode));
|
|
|
|
QVariantMap::const_iterator it = headers.constBegin();
|
|
|
|
while(it != headers.constEnd()) {
|
|
|
|
mg_printf(m_conn, "%s: %s\r\n", qPrintable(it.key()), qPrintable(it.value().toString()));
|
|
|
|
++it;
|
|
|
|
}
|
|
|
|
mg_write(m_conn, "\r\n", 2);
|
2011-11-05 19:38:08 +04:00
|
|
|
}
|
|
|
|
|
2011-12-20 06:18:08 +04:00
|
|
|
void WebServerResponse::write(const QString &body)
|
2011-11-05 19:38:08 +04:00
|
|
|
{
|
2011-11-07 20:33:35 +04:00
|
|
|
if (!m_headersSent) {
|
2011-12-20 06:18:08 +04:00
|
|
|
writeHead(m_statusCode, m_headers);
|
2011-11-07 20:33:35 +04:00
|
|
|
}
|
|
|
|
///TODO: encoding?!
|
|
|
|
const QByteArray data = body.toLocal8Bit();
|
|
|
|
mg_write(m_conn, data.constData(), data.size());
|
|
|
|
}
|
|
|
|
|
2012-02-10 22:42:38 +04:00
|
|
|
void WebServerResponse::close()
|
|
|
|
{
|
2012-03-14 18:45:53 +04:00
|
|
|
m_close->release();
|
2012-02-10 22:42:38 +04:00
|
|
|
}
|
|
|
|
|
2011-11-07 20:33:35 +04:00
|
|
|
int WebServerResponse::statusCode() const
|
|
|
|
{
|
|
|
|
return m_statusCode;
|
|
|
|
}
|
|
|
|
|
|
|
|
void WebServerResponse::setStatusCode(int code)
|
|
|
|
{
|
|
|
|
///TODO: what is the best-practice error handling in javascript? exceptions?
|
|
|
|
Q_ASSERT(!m_headersSent);
|
|
|
|
m_statusCode = code;
|
|
|
|
}
|
|
|
|
|
|
|
|
QString WebServerResponse::header(const QString &name) const
|
|
|
|
{
|
|
|
|
return m_headers.value(name).toString();
|
|
|
|
}
|
|
|
|
|
|
|
|
void WebServerResponse::setHeader(const QString &name, const QString &value)
|
|
|
|
{
|
|
|
|
///TODO: what is the best-practice error handling in javascript? exceptions?
|
|
|
|
Q_ASSERT(!m_headersSent);
|
|
|
|
m_headers.insert(name, value);
|
|
|
|
}
|
|
|
|
|
|
|
|
QVariantMap WebServerResponse::headers() const
|
|
|
|
{
|
|
|
|
return m_headers;
|
2011-11-05 19:38:08 +04:00
|
|
|
}
|
|
|
|
|
2011-11-07 20:33:35 +04:00
|
|
|
void WebServerResponse::setHeaders(const QVariantMap &headers)
|
|
|
|
{
|
|
|
|
///TODO: what is the best-practice error handling in javascript? exceptions?
|
|
|
|
Q_ASSERT(!m_headersSent);
|
|
|
|
m_headers = headers;
|
|
|
|
}
|
2011-11-05 19:38:08 +04:00
|
|
|
|
A REPL for PhantomJS
This covers [Issue 252](http://code.google.com/p/phantomjs/issues/detail?id=252)
The commit is composed of 12 squashed commits:
commit efdc6ba4f143c30a690fd97d92d80fa412e79999
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Mon Feb 27 00:19:36 2012 +0000
Pretty-pringing and Completion Caching done!
* This completes pretty-printing for the result of evaluated
* expressions in the REPL.
* Also, now we cache the "possible completions", to speed things up
* a bit (nothing fancy though).
* Minor tweaks to the internal doc and the way we "mock"
* pretty-printing for QObjects/REPLCompletanle
* All tests passing :)
commit 1f9ef690e112a535b431fca409b77bb9c09d1c70
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Sun Feb 26 22:35:00 2012 +0000
Moving most of REPL shim JavaScritp code in a separate file. Way
easier to work on.
commit 02d460a16fee14e7096ae7d899c03902c5b8a9c6
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Sat Feb 25 20:25:18 2012 +0000
Initialisation of the Completions is now done in a pure virtual.
This means that every REPLCompletable object will ACTUALLY register
completion strings, ONLY if we are running a REPL
and that object is ACTUALLY created.
Otherwise, why bother?
Adding completions for all exposed REPLCompletable objects
Also, fixed an issue with _getCompletions()
commit 412c3778fb04aa1c7379f8e760afce702b0428dd
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Tue Feb 21 00:49:17 2012 +0000
Few more tweaks to the REPL:
- Now 'phantom' is the first QObject with proper completion
- No repetition in QObject completions
- LVAL of any user expression is now correctly prettified and
printed
Major things left to do:
- Cache completions (using QCache?)
- Add completions for the other QObject
- When the LVAL of a user expression is a QObject, print what's
expected, not the QObject "real" structure
commit 46f04713c8165d898055e15478bb31403f8c93f1
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Tue Feb 7 10:13:23 2012 -0800
Pretty-print expressions result
Still not done though: there are issues with the NON-Native JS
objects.
commit 98b2fe67651dc750b62c6fa9cf1d80317fd9ae06
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Fri Feb 3 00:22:52 2012 -0800
Introducing REPLCompletable.
This class should be inherited by any JavaScript-exposed QObject, to
ensure correct Auto-Completion.
Correct auto-completion for QObjects.
- Now even QObjects can correctly provide auto-completion, and avoid
showing "not for users" methods
- The strings used for the auto-completion are stored in a single
Index: minimum memory footprint
- Still, there is optimization that should be done (when "searching"
for the right completion by prefix)
- Completion for the objects not set up yet, but now it's just a
trivial sequence of "addCompletion('bla')" in their constructors
commit 9bd48618154b1530a37b41f4060440184e23253d
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Thu Feb 2 00:20:25 2012 -0800
Changing the way we import Linenoise.
Will just import a specific commit, and update manually when needed.
commit cfc9bae9fbdab13b01019b34b7cbd565e3153780
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Sun Jan 29 23:22:26 2012 -0800
Made the REPL into a Singleton. With Auto-completion!.
Reasons:
1) Needed a pointer to function (i.e. a static method) to be used
with Linenoise to provide auto-completions
2) It makes more sense, as it's not like we are going to have 2 REPL
running at the same time, are we?
There are problems to address:
- the enumeration in JS seems to return only the native interface of
our objects
- the function completions contain argument types of those functions
- "private" methods are exposed
commit c78bd32e17f8e0e4cc4a0066858de8cc81d33b97
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Sun Jan 29 22:10:20 2012 -0800
Migrating from the original, now [unmantained
Linenoise](https://github.com/antirez/linenoise) to the fairly active
[tadmarshall fork](https://github.com/tadmarshall/linenoise).
Also now the project is imported as a Git Submodule.
Having migrated to the latest Linenoise (see prev. commit), now this
_SHOULD_ work on Windows too.
But, of course, this needs testing. :)
commit 43713c5723d7c5ed446ba41ae8d6f8c9feba7f9b
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Tue Jan 24 23:17:06 2012 -0800
Now that the basics work, I'm adding support for REPL history.
This is something almost everyone today is accustomed to.
Also, now REPL history works!
And I found some useful resources to solve pending TODOs.
commit 31e5f88b044a5b4a823c67527ef8c245d2ac7863
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Sun Jan 22 20:56:36 2012 -0800
Adding Linenoise Project (https://github.com/antirez/linenoise).
For now is included as a drop-in set of files.
Later on, if the Linenoise project has frequent
updates, we might prefer to do it as a
git-submodule.
commit 4be9c15c65db4767e482fba0be13f8aab286d5f3
Author: Ivan De Marino <ivan.de.marino@gmail.com>
Date: Thu Jan 5 15:31:13 2012 +0000
First simple REPL implementation.
- Not complete
- Still doesn't handle arrow keys (needed for history)
2012-01-05 19:31:13 +04:00
|
|
|
void WebServerResponse::initCompletions()
|
|
|
|
{
|
|
|
|
// Add completion for the Dynamic Properties of the 'webpage' object
|
|
|
|
// properties
|
|
|
|
addCompletion("statusCode");
|
|
|
|
addCompletion("headers");
|
|
|
|
// functions
|
|
|
|
addCompletion("writeHead");
|
|
|
|
addCompletion("write");
|
|
|
|
}
|
|
|
|
|
2011-11-05 19:38:08 +04:00
|
|
|
//END WebServerResponse
|