Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add API to HttpServerResponse to force writing the headers #47

Open
zecke opened this issue Aug 23, 2014 · 3 comments
Open

Add API to HttpServerResponse to force writing the headers #47

zecke opened this issue Aug 23, 2014 · 3 comments
Labels

Comments

@zecke
Copy link

zecke commented Aug 23, 2014

When a new request is received I am doing something a long:

    resp.writeHead(Tufao::HttpResponseStatus::OK);
    resp.flush();

The application will process some data (when it arrives) and then issue the resp.write with the data that was received. Quite some time can pass between the resp.writehead and the first resp.write. In the client I am using QNAM and the metaDataChanged() signal is only emitted once the first piece of data was written. I would love to force the writing of the Keep-Alive and Transfer encoding.

It would be great to have some API that prevents me from issuing a resp.write(" ") just to force the writing of headers.

@vinipsmaker
Copy link
Owner

As you can see on the doc:

[...] they will be automatically flushed when the first piece of body is written.

This is meant to be an useful abstraction, then I won't change the behaviour. flush() won't help you.

So, if I understood correctly, you cannot use end() because your message has a body and you would like to let the HTTP client to have access to the headers as soon as possible. You could use the writeHead() method taking a Headers object as argument. It's not documented to do that, but it is what it does. I'll leave this bug open until I fix the documentation. Does this solve your problem?

@zecke
Copy link
Author

zecke commented Aug 25, 2014

That is a neat idea, I didn't look for other writeHead overloads. Unfortunately QNAM seems to only trigger metaDataChanged at the end of all headers. I understand that the issue is in QNAM and it is more than fine if you don't want to provide API to deal with such quirks.

@vinipsmaker
Copy link
Owner

Unfortunately QNAM seems to only trigger metaDataChanged at the end of all headers

I see.

Another improvement would be to interpret a write(QByteArray()/*empty body*/) as a desire to send the headers. Do you think this would solve your problem?

Also, what Tufão series are you using (0.x, 1.x), then I can deliver the solution for this series first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants