Qt-interest Archive, May 2008
QSslSocket ready() slot - where is it ?
Pages: Prev | 1 | 2 | Next
Message 16 in thread
Arnold Krille wrote:
> Am Montag, 19. Mai 2008 schrieb Thiago Macieira:
>> On Monday 19 May 2008 15:38:18 Stephen Collyer wrote:
>>> Thiago Macieira wrote:
>>>> Not to mention the security risk associated with it.
>>> I'm not sure I see any particular security risk - if someone needs
>>> an HTTP server, they have to handle any security issues just as much
>>> if they wrote the code as if Trolltech wrote it.
>> Yeah, but who gets the blame if there's an issue? :-P
>
> Especially as some people pay for using (and relying on) Qt...
I don't understand the "blame" problem: Trolltech would get
the "blame" for any security problem in any part of Qt, and
given that there's already good support for networking, there's
more than enough rope already in Qt for someone to hang themselves
with if they want to write an insecure server for any protocol.
> @Stephen: Maybe its easier for you to rip apache/lighttp for the parts you
> need instead of trying to reinvent the wheel?
Thanks but I've already done the work (or at least as much
as I need - and I suspect you underestimate the amount of
effort needed to a) understand the existing code and b)
integrate it cleanly into a Qt application)
--
[ signature omitted ]
Message 17 in thread
On May 19, 2008, at 9:38 AM, Stephen Collyer wrote:
> Is that "No, never", or "No, but yes if we had enough people to do
> it" ?
Since there are freely available implementations of HTTP and FTP
servers, what use would an implementation by TrollTech serve?
Brad
--
[ signature omitted ]
Message 18 in thread
Brad Howes wrote:
> On May 19, 2008, at 9:38 AM, Stephen Collyer wrote:
>
>> Is that "No, never", or "No, but yes if we had enough people to do it" ?
>
> Since there are freely available implementations of HTTP and FTP
> servers, what use would an implementation by TrollTech serve?
Well, you could say that about just about every aspect of
the existing Qt code base, but Trolltech and their customers
obviously see some use ..
The main advantage of a Trolltech HTTP server subclassed from, say,
QTcpServer (or would it be QTcpSocket ?) is that it would be a native
class, presumably exposing its functionality via signals and slots,
with all the nasty details hidden away, and with request details
available in QHttpRequestHeader objects, and so on. Then
you could write:
class MyHTTPServer: QHttpServer
{
..
};
connect(myhttpserver, SIGNAL( getCompleted()) , this, SLOT( handleGET())
void MyHTTPServer::handleGET(QHttpRequestHeader reqheader)
{
// hmm, we've seen a GET request - let's send back what it wants
QHttpResponse respheader;
if (reqheader.path() != "/etc/passwd")
{
..
}
}
and so on. That would be much nicer than hacking Apache
internals, no ?
--
[ signature omitted ]
Message 19 in thread
On 5/19/08, Thiago Macieira <thiago.macieira@xxxxxxxxxxxxx> wrote:
> And that's because servers generally cope with broken clients, not
> the other way around. Implementing the server would probably be double that
> effort, at least, plus a good deal of testing with different User Agents.
To give a simple example of this, here's what apache does when you
give it a stupidly broken HTTP request:
rich@richm:~$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
gget / hTTp/1.0
HTTP/1.1 301 Moved Permanently
Date: Mon, 19 May 2008 19:15:35 GMT
Server: Apache
Location: http://xmelegance.org/
Content-Length: 230
Connection: close
Content-Type: text/html; charset=iso-8859-1
As you can see, it handles it as if it was ok then carries on. Even
more than that, if you did the same thing on port 443 then rather than
simply erroring because you failed the SSL encryption handshake, it
sends you a valid HTTP response telling you you're talking HTTP to an
HTTPS server.
Cheers
Rich.
--
[ signature omitted ]
