I am just looking at some old exam papers for an exam I have tomorrow and I know the answers to the majority of the questions (hopefully!) but I am not sure about how to put them, i.e how HTTP functions, what is sent, when and where. Would anyone be able to point me in the direction of somewhere I could learn about this, or possibly explain it here ?
The questions we are getting are of this style :
Ten HTTP requests arrive at port 80 on IP address 192.168.0.0;
state what the contents of the response body will be, in particular give the absolute pathname of the file,if any, that will be served in the response body; and explain in detail why this response body will be served.
I am able to work out what the contents should contain, but I am not sure how HTTP structures the information, I know how to work out the absolute pathname of the file I think, is the response body just the contents of the HTTP packet being sent back to the client ?
Thanks a lot for the help with this.
The response body is the information part of the packet that is sent. The packet as-is contains more information then that. You can look it up here: http://en.wikipedia.org/wiki/IPv4#Packet_structure
I believe the response body you mention refers to the "data" part of an http packet.
I do not see why there -has- to be an absolute filename involved. If it is a http file request the absolute file name would depend on so many things (which server is being used, which config etc.) I do not see how there can be a general answer to this.
The question is very strange - what if there is not even a webserver installed? :P And the response most definately depends on what kind of server is running, what modules are installed etc. wihthout that information and what the requests actually are it seems difficult to answer the question.
Related
As i know, when client send http request to server, for safety reason we should not send secret param on request url.
A lot of people say we should use body to attach parameter, i do agree
But what if i use header to send them? Is it safe like body? Somebody say it is not safe like body but could not explain why, please help
Thank
Just open debug console in your browser and you will see there are no difference. From TCP perspective, all the request is just a text file with few new lines between headers and body. And once you send requests over not encrypted channel (http), everything can be captured by the man in the middle. No safe place. On hte other hand, if you use https, your connection is encrypted (on lower level - TCP) and both body and headers are safe enough to transsmit sensitive information. The only "wrong" place even on https is URL, as someone behind your shoulder can see your secrets in browser's address bar.
Last week I started quite a fuss in my Computer Networks class over the need for a mandatory Host clause in the header of HTTP 1.1 GET messages.
The reason I'm provided with, be it written on the Web or shouted at me by my classmates, is always the same: the need to support virtual hosting. However, and I'll try to be as clear as possible, this does not appear to make sense.
I understand that in order to allow two domains to be hosted in a single machine (and by consequence, share the same IP address), there has to exist a way of differentiating both domain names.
What I don't understand is why it isn't possible to achieve this without a Host clause (HTTP 1.0 style) by using an absolute URL (e.g. GET http://www.example.org/index.html) instead of a relative one (e.g. GET /index.html).
When the HTTP message got to the server, it (the server) would redirect the message to the appropriate host, not by looking at the Host clause but, instead, by looking at the hostname in the URL present in the message's request line.
I would be very grateful if any of you hardcore hackers could help me understand what exactly am I missing here.
This was discussed in this thread:
modest suggestions for HTTP/2.0 with their rationale.
Add a header to the client request that indicates the hostname and
port of the URL which the client is accessing.
Rationale: One of the most requested features from commercial server
maintainers is the ability to run a single server on a single port
and have it respond with different top level pages depending on the
hostname in the URL.
Making an absolute request URI required (because there's no way for the client to know on beforehand whether the server homes one or more sites) was suggested:
Re the first proposal, to incorporate the hostname somewhere. This
would be cleanest put into the URL itself :-
GET http://hostname/fred http/2.0
This is the syntax for proxy redirects.
To which this argument was made:
Since there will be a mix of clients, some supporting host name reporting
and some not, it just doesn't matter how this info gets to the server.
Since it doesn't matter, the easier to implement solution is a new HTTP
request header field. It allows all clients and servers to operate as they
do now with NO code changes. Clients and servers that actually need host
name information can have tiny mods made to send the extra header field
containing the URL and process it.
[...]
All I'm suggesting is that there is a better way to
implement the delivery of host name info to the server that doesn't involve
hacking the request syntax and can be backwards compatible with ALL clients
and servers.
Feel free to read on to discover the final decision yourself. But be warned, it's easy to get lost in there.
The reason for adding support for specifying a host in an HTTP request was the limited supply of IP addresses (which was not an issue yet when HTTP 1.0 came out).
If your question is "why specify the host in a Host header as opposed to on the Request-Line", the answer is the need for interopability between HTTP/1.0 and 1.1.
If the question is "why is the Host header mandatory", this has to do with the desire to speed up the transition away from assigned IP addresses.
Here's some background on the Internet address conservation with respect to HTTP/1.1.
The reason for the 'Host' header is to make explicit which host this request refers to. Without 'Host', the server must know ahead of time that it is supposed to route 'http://joesdogs.com/' to Joe's Dogs while it is supposed to route 'http://joscats.com/' to Jo's Cats even though they are on the same webserver. (What if a server has 2 names, like 'joscats.com' and 'joescats.com' that should refer to the same website?)
Having an explicit 'Host' header make these kinds of decisions much easier to program.
I hope i will explain my question correctly.
I would like to make a request, to a url or a entity that lives at some port or address
and whatever is listening at that port will take the request and run with it, but will not
respond at all and neither will the client wait for the response, it will continue doing what needs to be done next,
the server or whatever is listening on that port will do what instructions i layed out in the request and that is it, i do not need confirmation whether what i wanted done got done
is this possible?
if i could sum up my questions it would be how can i make non-blocking to the client http requests to a listener on a remote host
if it is not possible, please explain to me why in short or point me where i could find this info.
Your question embodies a contradiction in terms. HTTP is a request/response protocol.
yeah, when you run -
http.get(myUrl)
with a callback missing, the computer sits around waiting for the response anyway. It's kinda weird, but it's a tenet of HTTP.
you may be interested in UDP, which is more "fire-and-forget", and somewhat similar in the node API. (It's got some gotchas though too!)
Does anyone know the usage of "Proxy-agent" response header ?
Proxy-Agent: is a non-standard header - it is not defined by any HTTP RFC. As a result, it should technically be X-Proxy-Agent:. If you want a definition of anything about the way that HTTP works, RFC 2616 is your bible.
Because it is non-standard, there is no definite answer to this question. At a guess, from the name of the header, it would contain the name of the HTTP proxy software that is handling the request on behalf of the User-Agent:. But, because it is non-standard, what it actually means could be something completely different.
What I can tell you is that, because it is non-standard, it is not likely to be pertinent to the way you handle the request - although it likely informs you that there is at least one proxy somewhere along the route between the client and the server.
I'm still starting out with Lua, and would like to write a (relatively) simple proxy using it.
This is what I would like to get to:
Listen on port.
Accept connection.
Since this is a proxy, I'm expecting HTTP (Get/Post etc..)/HTTPS/FTP/whatever requests from my browser.
Inspect the request (Just to extract the host and port information?)
Create a new socket and connect to the host specified in the request.
Relay the exact request as it was received, with POST data and all.
Receive the response (header/body/anything else..) and respond to the initial request.
Close Connections? I suppose Keep-Alive shouldn't be respected?
I realize it's not supposed to be trivial, but I'm having a lot of trouble setting this up using LuaSockets or Copas --- how do I receive the entire request? Keep receiving until I scan \r\n\r\n? Then how do I pull the post data? and the body? Or accept a "download" file? I read about the "sink", but admittedly didn't understand most of what that meant, so maybe I should read up more on that?
In case it matters, I'm working on a windows machine, using LuaForWindows and am still rather new to Lua. Loving it so far though, tables are simply amazing :)
I discovered lua-http but it seems to have been merged into Xavante (and I didn't find any version for lua 5.1 and LuaForWindows), not sure if it makes my life easier?
Thanks in advance for any tips, pointers, libraries/source I should be looking at etc :)
Not as easy as you may think. Requests to proxies and request to servers are different. In rfc2616 you can see that, when querying a proxy, a client include the absolute url of the requested document instead of the usual relative one.
So, as a proxy, you have to parse incomming requests, modify them, query the appropriate servers, and return response.
Parsing incomming requests is quite complex as body length depends on various parameters ( method, content encoding, etc ).
You may try to use lua-http-parser.