I can't find anything about the subprotocol used with WebSockets. What is the difference between "chat" and "superchat" subprotocol mentioned in the rfc6455 and where can I find the RFC for "chat" and "superchat" or are they just placeholders?
Both protocols don't exist, so there's no actual difference between them.
These "protocols" were just example name for possible Sec-WebSocket-Protocol header values.
It's pretty much the same as using foo and bar as example names, except they chose chat and superchat as example names.
As previously mentioned, those two names were just meant as examples. The protocol header itself is completely optional, but meant to provide a way to document what sort of dialogue/application this connection is supposed to handle.
In what seems to me to perhaps be a bit of over-engineering or premature bureaucracy, the relevant but "non-normative" RFC section in fact goes to length establishing an IANA registry of WebSocket Subprotocols. What seems to confuse people is that chat and superchat are not listed there.
Related
I am implementing a WebSocket server in C and was wondering what's the purpose of the text/binary frame indicators (opcode 1 and 2). Why they are there? In the end in both cases the payload contains bits. And when there is a protocol using websocket or so then I know what expect in the data. Is it because when it's a text message I can be sure that payload only contains UTF-8 valid data?
I will start my answer by pointing out that WebSockets are often implemented with a Javascript client in mind (i.e., a browser).
When you're using C, the different opcode might be used in different ways, but when using Javascript, this difference controls the type of the data in the event (Blob vs. String).
As you point out in the question, a string is always a valid UTF-8 stream of bytes, whereas a blob isn't.
This affects some data transport schemes (such as JSON parsing, which requires a UTF-8 valid stream).
Obviously, in C, this opcode could be used in different ways, but it would be better to use the opcode in the same manner as a potential javascript client.
P.S.
There are a number of Websocket C libraries and frameworks out there (I'm the author of facil.io).
Unless this is a study project, I would consider using one of the established frameworks / libraries.
What online resource is the authority for the complete set of ASN.1 definitions for the SNMP data structures used to request and respond with information? I am interested in versions 2c and version 3.
In RFC 3416 Section 3, I have found most of the definitions needed to use version 2c. However, the document has no mention of something that I have found on other resources referred to as the "snmpv2 message". For example, this shows up in the SNMP Programmers Reference Wiki and in the blog post Simple? Network Management Protocol. It's the data structure that contains the community string, so it's role is essential, but I cannot find where the authoritative source (probably an RFC) with an ASN.1 definition.
Similarly, I cannot find any authoritative ASN.1 definitions of SNMPv3 data structures. I found an ASN file in a github repo's test suite, but I cannot find where this information was taken from.
I would appreciate any help locating these. I'm usually a pretty good Googler, but my usual strategies are not turning anything up beyond what I've already linked to.
SNMP v3 message format is defined in RFC3412 page 19 as section 6 as ASN.1.
SNMP v2c reuses most of v1 message format, except defining new message body (PDU). I think that's why in RFC 3416 you don't see all details, because it only mentions the new PDU definitions for simplicity.
You might want to dig ASN.1 documents out of SNMP RFCs:
Base data types, RFC2578
SNMP v2c message, RFC3416
SNMP v3 message, RFC3412
SNMP v3 USM, RFC3414
I have been starting to see uggc/uggcf (rot-13 encoded http/https) links show up in our system.
Are these worth supporting, is there actually a demand for it? The IETF document (link) has not been touched since 2001 and I cannot find much information on them at all.
Is there an area of the world where this is more common? I've only noticed them since we went world-wide.
The document describes it as a method to 'secure' the url as well as the data. What is the value of rot-13 encoding the data if it can be reversed without a key? HTTPS handles all of this, except for the domain itself.
I know this is an old answer but this is an interesting topic so I'll try to answer your question:
The "Encrypted Hypertext Transfer Protocol -- UGGC/1.0" specification, is an April Fools RFC. The IETF releases these almost yearly on 1st April, and ROT13 "encryption" would be pointless, since by knowning the encryption algortihm, you would be able to "decrypt" the message, in this case the URL.
So no, it's not worth supporting, and it does not provide any "serious" protection. The only usage I've seen is in some CTFs or hacking/crypto challenges.
I am working on a project where we are using protocol buffers to create and parse some of our messages (protobuf-net). This is so elegant, that I would like to use this same deserialization method to parse other messages emanating from external non-protobuf generated sources. Is this possible?
I would imagine that it could be possible to specify all of the .proto fields to be fixed size (i.e. not like variable ints). The question is then whether you could replace the protobuf headers with other magic numbers or whichever header the 3rd party protocol uses.
If this is a bit confusing, an example may shed some light:
Let's say you buy a fancy toaster that exposes an ethernet port. It supports a proprietary but well documented protocol. Can you burn heart shaped patterns on your toast using protobuf?
At the moment, no: the library is tied to the protobuf wire specification; it does not have support for non-protobuf data.
In a way, it is a bit like asking: "can XmlSerializer read/write json?". It isn't something that is on my list of things to look at, to be honest.
Is there a summary anywhere of the protocol difference between the various WebSockets drafts?
The browser support levels are still all over the place, so it is not sufficient just to consider the RFC.
Obviously the Sec-WebSocket-Version changes, and I know the early format was pretty radically different. However, I mean the more subtle changes in the protocol. For example, hybi-10 (v8), in framing, suggests the extended payload length is stored as 16/63, rather than 16/64 in RFC 6455 (v13).
So: is there a summary of changes anywhere?
Alternatively (if we ignore the very early drafts, and the version numbers), is it the case that the protocol is essentially the same, and that the drafts are mainly corrections to the specification text?
The Wikipedia WebSocket lists which browsers support which protocol.
Also, the IETF provides an diff tool that can be used to compare any two RFC draft specifications. For example, to compare WebSocket draft 15 and 17 go here:
http://tools.ietf.org/rfcdiff?url1=draft-ietf-hybi-thewebsocketprotocol-15.txt&url2=draft-ietf-hybi-thewebsocketprotocol-17.txt
Adjust the url1 and url2 addresses to get a diff for arbitrary versions. Note that this will shows you textual differences to the spec and large changes to the spec often happen without corresponding differences on the wire. I suggest searching the diffs for the "Protocol Overview" section and the "Base Framing Protocol" section which show the header summary and the framing diagram respectively.
The biggest difference in the wire protocol occured between Hixie-76/HyBi-00 (HyBi-00 was just a copy of Hixie-76 for starting the new series) and the rest of the HyBi series starting with HyBi-04 (HyBi-17 became IETF RFC 6455). Some of the major changes from the Hixie series to the HyBi series:
In the Hixie-76 protocol, there was a peculiar hash handshake that happened after the handshake headers but before the actual data frames.
In Hixie-76, the frames were prefixed with 0x00 and suffixed with 0xff. There was no way to determine the length of the frame except by receiving/buffering all the way to the end of the frame. In the HyBi series (after HyBi-00) the frame length is part of the prefix/header and there is no suffix.
The HyBi series supports both UTF-8 text and binary data in the payload (Hixie only supported UTF-8). This is indicated by and opcode in the frame header.
To add a specific change; in Sec-WebSocketVersion <= 8, the origin is in Sec-WebSocket-Origin; however, in 13 this changes to the Origin header. This changes specifically between hybi-10 and hybi-11, which are both version "8" implementations. Also note that it is Origin in hixie-76/hybi-00, so it looks like it went from Origin to Sec-WebSocket-Origin and then back to Origin.
I'm not aware of many of the protocol versions being in current use. I have a websocket server which supports Hixie-76 and hybi-10 through 17 (just changes in Sec-WebSocket-Version) which works against Safari (desktop + iOS), Firefox and Chrome.
(The older) Hixie-76 is useful for talking to iOS devices at least.
hybi-10 onwards are essentially the same. I'd assumed that your example of the extended payload being advertised as 63 bits in hybi-10 was a typo and was one of the many small corrections made when the drafts moved rapidly from 10 to 17.
Later: edited to show that some Safari versions actually use Hixie-76