Comments (6)
Can you have a try to give an answer?
I didn't quite understand what is the question. Can you elaborate a little more?
Even if I didn't understand the question, it reminds me of the differences between Tufão 0.x and 1.x.
from tufao.
Tks for reply me !!, I have an example here with 2 handlers: Handler1, Handler2
class Handler1 : public Tufao::AbstractHttpServerRequestHandler
{
.......
public slots:
bool handleRequest(Tufao::HttpServerRequest *request,
Tufao::HttpServerResponse *response,
const QStringList &args);
void onEndRequest();
};
class Handler2 : public Tufao::AbstractHttpServerRequestHandler
{
..........
public slots:
bool handleRequest(Tufao::HttpServerRequest *request,
Tufao::HttpServerResponse *response,
const QStringList &args);
void onEndRequest();
};
In slot handleRequest, I have:
connect(request, SIGNAL(end()), this, SLOT(onEndRequest()));
In slot onEndRequest(), I log this:
handler1.cpp: qDebug() << "END ACCESS HANDLER 1";
handler2.cpp: qDebug() << "END ACCESS HANDLER 2";
In main:
router.map(QRegExp("^/handler1"), &hand1)
.map(QRegExp("^/handler2"), &hand2);
So every request comes to handler will go through handleRequest, right? Request to /handler1 comes to handleRequest of Handler1, and request to /handler2 comes to handleRequest of Handler2. And when request ends, it will go to onEndRequest().
First time I request to /handler1. it logs:
"END ACCESS HANDLER 1";
Second time, it logs double:
"END ACCESS HANDLER 1";
"END ACCESS HANDLER 1";
Third time, it becomes trible:
"END ACCESS HANDLER 1";
"END ACCESS HANDLER 1";
"END ACCESS HANDLER 1";
And request to /handler2, it logs:
"END ACCESS HANDLER 1";
"END ACCESS HANDLER 1";
"END ACCESS HANDLER 1";
"END ACCESS HANDLER 2";
It seems the previous requests haven't ended yet. They still emit the signal end() and the handlers still catch this signal.
Can you explain for me this situation ? Tks alot
from tufao.
Can you explain for me this situation ? Tks alot
Well, this is one of the differences between Tufão 0.x and Tufão 1.x and I used an alternative approach in Tufão 1.x because I acknowledged the lack of intuitiveness:
[In Tufão 1.x]
HttpServerRequest::ready
signal auto-disconnects all slots connected to theHttpServerRequest::data
andHttpServerRequest::end
slots before being emitted.
To understand what it is happening, you just need to realize that HttpServerRequest
will NOT abstract a single session (i.e. a pair of request and reply). HttpServerRequest
will abstract a whole connection. The object is reused for other pairs of requests and replies within the same connection. So, before you're done with the object, you need to unglue all callbacks that you configured before.
Currently, this is what is happening to your code:
- A connection is initiated, then a HttpServerRequest object is created.
- A request on this connection is ready, so the
ready
signal is emitted. - On the
onReady
slot, you add a connection on thedata
signal. - (Whatever, a lot happens)
- A new request is ready on the same connection, so, for the same object, the
ready
signal is once again emitted. - On the
onReady
slot, you add a new and fresh connection on thedata
signal. But this new signal-slot connection is redundant, because there was a previous connection that is identical to the new one. Now, you have two connections and the slot will be called two times.
Was I clear?
Fix: On the onEnd
slot, clear all connections that you have made on the onReady
slot.
Alternative fix: Use Tufão 1.x, as it will automatically disconnects all slots connected to the HttpServerRequest::data
and HttpServerRequest::end
slots before emitting the ready
signal. I cannot backport these changes to Tufão 0.x because I have a compromise on API stability and the change would break how you use the API.
from tufao.
Thank you so so much. Unfortunately, I must use Qt 4.7 so I can't use Tufao 1.x. But if I don't handle the ready signal, how can I clear all previous connections ? Can you give me an example
from tufao.
But if I don't handle the ready signal, how can I clear all previous connections ?
There isn't much secret here. The trick is to ensure there is only one signal-slot connection. You can even use Qt::UniqueConnection, but I cannot recommend this as a general case because it's very easy to create bugs. You must be careful and understand what you're doing because HTTP is stateless and data artifacts from one pair of request and response must not escape to another unrelated pair of request and response.
Anyway, in handleRequest
, just clear all slots connected to the data
and end
signals before doing anything. But this must be done for the whole project.
Can you give me an example
I'm on the middle of a timeline now, so I cannot give much resources to this issue now. If you remind me on January 2 (or later), I believe I'll have the time to elaborate an example.
from tufao.
Thank you, I appreciate it a lot
from tufao.
Related Issues (20)
- Data is truncated when using WebSocket to transfer data over 128k HOT 2
- can't link apps in debug mode on VS HOT 6
- apps hang when linked to wrong library configuration on VS
- problem using HttpServerRequestRouter with Visual Studio HOT 2
- typo in httpserverrequestrouter.cpp
- Only the first cookie is considered HOT 1
- doc: ldconfig after install HOT 1
- Move news section from README.md to CHANGELOG.md
- Add some more shields from Shields.io
- SIGSEGV when using int HttpServerRequestRouter::map(std::initializer_list<Mapping> map) HOT 1
- Socket stops to accept connexion
- Loop parsing POST contains request with two "readyRead" HOT 5
- websocket transform large data data loss HOT 2
- Remove an unnecessary null pointer check HOT 1
- Create Conan package
- Unable to find the Boost header files. Please set BOOST_ROOT to the root directory containing Boost or BOOST_INCLUDEDIR to the directory containing Boost's headers. HOT 1
- server close connection after server response client HOT 2
- How to interact with HTML file
- incoming urls with # i.e http://localhost/#index.html HOT 4
- What is the maximum amount of data for a single transfer? HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tufao.