I've implemented a Netty Snoop-like HTTP server and client.
The server can be tested easily with a browser - it works as expected. The client is harder to test but through debugging I can tell that it receives the headers just fine but it doesn't seem to receive the HTTP response body.
Since I know the server is sending the body (by checking in the browser) I'm wondering why the client code can't see it, or maybe can't decode it.
I am using Netty 4.0.15 as it appears to be the most stable release right now. You can see my version of the ClientHandler and ClientInitalizer classes at http://pastebin.com/tQ6d72pn And you can see my ServerHandler and ServerInitalizer classes at http://pastebin.com/JbHrTEkg
No doubt I'm doing something stupid, any help would be really great!
Related
From a win32 HTTP server I have to send a big (~32MB) message to an angular based client running in chrome.
Must I use Websocket for this purpose ?
Or should I use Server-sent-events (SSE) ?
What are my alternatives ?
Thank you,
Zvika
Neither Websocket nor SSE are for sending large messages specifically and it makes sense to use specifically for solving this problem.
HTTP works perfectly fine with large responses, even if it's gigabytes. Try it. If you run into problems report back here with detailed explanations of what failed.
What are good "bad HTTP client"-s I can use to test your HTTP servers?
For instance, there are servers like
https://httpbin.org/
https://badssl.com/
which allow you to test client against different, sometimes intentionally bad, behavior.
I seek for HTTP client utility for testing HTTP servers. It may send wrong Content-Length or close connection in the middle of request, or do other bad things which robust HTTP server should handle.
In the past, I have used Tamper Data (for Firefox). I see that there is an equivalent for Chrome - Tamper Chrome.
These plugins allow you to edit the HTTP request prior to sending it to the server. This way you can do a number of test cases e.g.:
Changing the content length or type
Bypassing the client-side field validation
These are great for manual, exploratory testing.
I couldn't find RFC that may answer this question. Perhaps you guys can point me to right direction.
I'm implementing strippeddown http server whose only function is to accept big multi-part encoded uploads.
In certain cases, such as file is too big or client is not authorized to upload, I want server to reply with error and close connection immediately.
It looks like Chrome browser doesn't like it because it thinks server returned http code zero.
Could not get any response
This seems to be like an error connecting to http://my_ubuntu:8080/api/upload. The response status was 0.
Check out the W3C XMLHttpRequest Level 2 spec for more details about when this happens.
Therefore question:
Is replying to client before receiving complete request allowed for HTTP server ?
update: Just tested it with iOS 6 client. Same thing, it thinks server abruptly closed connection :(
This is a great question and apparently it is very ambiguous. You will probably enjoy reading this article on the "Million Dollar Bug" - http://jacquesmattheij.com/the-several-million-dollar-bug
I think this is certificate trust issue. Try manually trusting the site and subsequent requests should work.
I'm trying to write a small program that I can talk to Omegle strangers via command line for school. However I'm having some issues, I'm sure I could solve the problem if I could view the headers sent however if you talk to a stranger on Omegle while Live HTTP Headers (or a similar plug-in or program) is running the headers don't show. Why is this? Are they not sending HTTP headers and using a different protocol instead?
I'm really lost with this, any ideas?
I had success in writing a command line Omegle chat client. However it is hardcoded in C for POSIX and curses.
I'm not sure what exactly your problem is, maybe it's just something with your method of reverse engineering Omegle's protocol. If you want to make a chat client, use a network packet analyzer such as Wireshark (or if you're on a POSIX system I recommend tcpdump), study exactly what data is sent and received during a chat session and have your program emulate what the default web client is doing. Another option is to de-compile/reverse engineer the default web client itself, which would be a more thorough method but more complicated.
I have an web application in which after making a HTTP request to the server, the client quits ( or network connection is broken) before the response was completely received by the client.
In this scenario the server side of the application needs to do some cleanup work. Is there a way built into HTTP protocol to detect this condition. How does the server know if the client is still waiting for the response or has quit?
Thanks
Vijay Kumar
No, there is nothing built in to the protocol to do this (after all, you can't tell whether the response has been received by the client itself yet, or just a downstream proxy).
Just have your client make a second request to acknowledge that it has received and stored the original response. If you don't see a timely acknowedgement, run the cleanup.
However, make sure that you understand the implications of the Two Generals' Problem.
You might have a network problem... usualy, when you send a HTTP request to the server, first you send headers and then the content of the POST (if it is a post method). Likewise, the server responds with the headers and document body. The first line in the header is the status. Usually, status 200 is the success status, if you get that, then there should be no problem getting the rest of the document. Check this for details on the HTTP response status headers http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html
LE:
Sorry, missread your question. Basically, you don't have a trigger for when the user disconnects. If you use OOP, you could use the destructor of a class to clean whatever it is you need to clean.