sf::HTTP - full HTTP/1.1 compliance

[nfries88]

Well, I see that the HTTP code in SFML is not completely compliant with the HTTP/1.1 standard (it doesn't accept 100 Continue or 101 Switching Protocols, among other things). I'm not even sure if it's completely compliant to the HTTP/1.0 standard.

Are there intentions to improve upon this?

[Laurent]

Yes of course, if there's something that can be fixed and/or improved, I'm always interested. However the HTTP implementation in SFML is not meant to be the most complete one ever, it focuses on the most common stuff.

I don't know all the details about HTTP 1.1 and 1.0, so maybe you can help me. What exactly do you think that SFML should support? What do the 100 and 101 statuses mean, when are they sent?

[nfries88]

Yes of course, if there's something that can be fixed and/or improved, I'm always interested. However the HTTP implementation in SFML is not meant to be the most complete one ever, it focuses on the most common stuff.

I don't know all the details about HTTP 1.1 and 1.0, so maybe you can help me. What exactly do you think that SFML should support? What do the 100 and 101 statuses mean, when are they sent?

The 100 status is "Continue", and can be ignored.
More: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.1.1

The 101 status is "Switching Protocols", it is normally sent when the client has requested to upgrade the protocol to a secure connection (https) from what I've read.
More: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.1.2
Client "Upgrade" command: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.42

The entire HTTP/1.1 reference can be read at http://www.w3.org/Protocols/rfc2616/rfc2616.html , but it's a bit overwhelming to try to do all at once. I would begin with those two statuses, maybe chunked transfer encoding if you haven't already, and commonly used client headers (Accept [used to describe what types of responses the client is looking for, and order of preference], Upgrade, Referer, User-Agent [to differentiate between IE, Firefox, Chrome, SFML, etc], and If-Modified-Since [used to hold a client-side cached page]), and support for compressed response bodies (Content-Encoding response header, either "compress" LZW or "gzip" LZ77 compression).

PS: That said, I'm looking at the HTTP/1.0 reference right now, and SFML actually has most of it. Only thing really missing is request parameters.

[Laurent]

The 100 status is "Continue", and can be ignored.

Ok.

The 101 status is "Switching Protocols", it is normally sent when the client has requested to upgrade the protocol to a secure connection (https) from what I've read.

SFML is not going to support HTTPS in a near future, as it requires either a lot of work or using external dependencies for SSL/TLS stuff.

maybe chunked transfer encoding if you haven't already

Yes, this is planned. It is required to enable file transfers, so I think it's quite important.

and commonly used client headers (Accept [used to describe what types of responses the client is looking for, and order of preference], Upgrade, Referer, User-Agent [to differentiate between IE, Firefox, Chrome, SFML, etc], and If-Modified-Since [used to hold a client-side cached page])

This is entirely left to the user, SFML won't provide helpers or predefined stuff for header fields. All it does is to fill mandatory headers if they are empty when the request is sent.

and support for compressed response bodies (Content-Encoding response header, either "compress" LZW or "gzip" LZ77 compression)

Same as HTTPS, it requires new external dependencies so it will probably wait a little bit