While taking a look at the rfc for socks version 5 I was wondering whether there are prior versions to socks5. And there was SOCKS4 but I was not able to find a RFC for SOCKS4 instead I found this document
https://www.openssh.com/txt/socks4.protocol
Which gave the implmentation details of SOCKS4. My question is that is there a RFC seperately for SOCKS4 if not why?
I'm new to networks and it would be great to know the answer for this question.
I want to know whether there is an RFC for SOCKS4
Related
Im just looking for the RFC of BitTorrent Protocol.
I reached to the document here is it but what is actually I want is the number of the RFC
You can actually google that.
https://www.rfc-editor.org/rfc/rfc5694
Nowadays, I'm reading Front-End Developer Handbook. Because I want to be successfull front-end developer. I've read Coderbyte's guide. There is also an HTTP suggestion in the article.
I researched for HTTP resources. i've found these links:
https://developer.mozilla.org/en-US/docs/Web/HTTP
http://httpwg.org/specs/
https://httpstatuses.com/
http://chimera.labs.oreilly.com/books/1230000000545/index.html
https://code.tutsplus.com/tutorials/http-the-protocol-every-web-developer-must-know-part-1--net-31177
https://code.tutsplus.com/tutorials/http-the-protocol-every-web-developer-must-know-part-2--net-31155
So, I'm looking for different resources to learn HTTP, DNS, Browsers. What are your suggestions to learn HTTP, DNS and Browsers?
Disclaimer: Don't be surprised if this question gets closed. Asking for this kind of resources is off topic here. I would post it a comment, but the content wouldn't fit well, hence I'm posting it as an answer.
RFCs
The RFC's 7230-35 are the official references for the HTTP/1.1 protocol and these document define how HTTP is supposed to work:
RFC 7230: Message Syntax and Routing
RFC 7231: Semantics and Content
RFC 7232: Conditional Requests
RFC 7233: Range Requests
RFC 7234: Caching
RFC 7235: Authentication
For the HTTP/2 protocol, consider the following RFCs:
RFC 7540: Hypertext Transfer Protocol Version 2 (HTTP/2)
RFC 7541: HPACK: Header Compression for HTTP/2
It is worthwhile to mention that documents such as RFC 1945, RFC 2068, RFC 2616 and RFC 2617 are obsoleted and must not be used as reference anymore.
In fact, RFCs are official references and are not meant to be tutorials. RFCs are like legal contracts. If you are looking for something close to a tutorial, I recommend the next resource below.
Mozilla Developer Network web docs
The MDN web docs about HTTP is also a credible source.
I found chapter one of the O'Reilly book "Designing Evolvable Web APIs with ASP.NET" to be a really good summary of HTTP. The book in general is aimed at .NET but the initial chapter is not.
You can read it online free: http://chimera.labs.oreilly.com/books/1234000001708/ch01.html
The most fundamental work from what I have read is The TPC/IP Guite
http://www.tcpipguide.com/free/t_TCPIPHypertextTransferProtocolHTTP.htm
you can call the book 'How the Internet works'
btw it's free
I'd suggest the free book: HTTP Succintly as a great starting point before deep diving into the RFCs.
Is it possible that tcp header patterns to behave differently from rfc specification in normal case(i mean when it is not any intrusion or anomaly)? or it will always follow rfc standard in all cases where there is no attack?
The RFC is there to be followed. A host that does not conform to the RFCs (a) cannot be connected directly to the Internet and (b) won't work correctly.
I need to programmatically determine the Router NAT type in my program. I did look at some of the STUN related answers and UPnP related information on SO. But did not get any definitive answers.
I looked at STUN RFC (rfc 5389) and it does not specify how to determine the NAT type. It does mention that it's previous version (RFC 3489) did provide the mechanism to determine NAT type. But also mentions that
Furthermore. classic STUN's algorithm for classification of NAT types was found to be faulty, as many NATs did not fit cleanly into the types defined there.
Given above, could you please advice on how I should go ahead with determination of router NAT type in my software. Further, now that RFC 3489 is obsoleted is there any other means?
Thanks in advance.
RFC 3489 was split into three different RFCs:
RFC 5389 - basic STUN protocol. Basic protocol of STUN binding request and binding response are largely the same as RFC 3489. The protocol header gets updated with a magic cookie occupying some of the transaction id field. Some STUN attributes get redefined. A few new ones added (specifically - XOR_MAPPED_ADDRESS). Some changes to how STUN auth is done. NAT behavior and classification discussion moved to RFC 5780.
RFC 5780 - "Nat Behavior discovery using STUN". The basic change to NAT type discovery was to distinguish NAT port mapping behavior separate from NAT filtering behavior. Whereas RFC 3489 would try to classify a NAT into one of several buckets ("cone", "port restricted", "symmetric") - which was just too generic to describe a NAT.
RFC 5769 - Just outlines what the hex dump of a few different STUN message types would look like.
Out of curiosity, I suppose knowing if your app is running behind a NAT is useful. But how would knowing the NAT's behavior influence your code path?
Shameless plug - Use my STUN Server code that is hosted on GitHub.
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.