edualb/ghype

ghype is an http/1.1 library built in Go

👽🍁 Welcome 🍁👽

About me 🔭

Fascinated by Software Development universe, I am graduated in Computer Engineering and I've been working as a Software Developer since 2017 with focus in backend developing using Go, C and Shell Script (sometimes Java and Javascript/Typescript). I am a quick learner and I am an easy-going person who will provide a really good team environment, commitment and sharing knowledge and experience to all teammates.

ghype's Issues

2.1 Client/Server Messaging

2.1 Client/Server Messaging

This section explains how the client and server can communicate. Once we want to implement just the server, we will be focus on the server implementations.

• HTTP is a stateless request/response protocol that operates by
  exchanging messages (Section 3) across a reliable transport- or
  session-layer "connection" (Section 6). An HTTP "server" is a program
  that accepts connections in order to service HTTP requests by sending
  HTTP responses.

• A server responds to a client's request by sending one or more HTTP
  response messages, each beginning with a status line that includes
  the protocol version, a success or error code, and textual reason
  phrase (Section 3.1.2), possibly followed by header fields containing
  server information, resource metadata, and representation metadata
  (Section 3.2), an empty line to indicate the end of the header
  section, and finally a message body containing the payload body (if
  any, Section 3.3).

6 Connection Management

6 Connection Management

RFC 7230 - Chapter 6

Connected issues:

• #5

Informations:

• The specific connection protocols to be
  used for an HTTP interaction are determined by client configuration
  and the target URI.
• For example, the "http" URI scheme
  (Section 2.7.1) indicates a default connection of TCP over IP, with a
  default TCP port of 80, but the client might be configured to use a
  proxy via some other connection, port, or protocol.

Tasks:

• Create a internal pkg called conn which will be responsible to handle connections. The
• Accept connections from inbound with default protocol as tcp and port 80 (the client could choose the port) and response with a message Hello World!

This issue is a WIP.

3. Message Format

RFC 7230 - Chapter 3

Connected issues:

• #5

Informations:

• The normal procedure for parsing an HTTP message is to read the
  start-line into a structure, read each header field into a hash table
  by field name until the empty line, and then use the parsed data to
  determine if a message body is expected. If a message body has been
  indicated, then it is read as a stream until an amount of octets
  equal to the message body length is read or the connection is closed.
• A recipient MUST parse an HTTP message as a sequence of octets in an
  encoding that is a superset of US-ASCII [USASCII].
• A recipient that receives whitespace between the
  start-line and the first header field MUST either reject the message
  as invalid or consume each whitespace-preceded line without further
  processing of it (i.e., ignore the entire line, along with any
  subsequent lines preceded by whitespace, until a properly formed
  header field is received or the header section is terminated).

Tasks:

• Implements startline structure
• request-line structure
• status-line structure
• implements request line logic

2.6 Protocol Versioning

Protocol Versioning

Section 2.6 RFC 7230

• Create a package inside of internal package called version
• Provide the major and the minor value that is 1 for both.
• Develop a function that will return the following HTTP-version using ABNF:

HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
HTTP-name     = %x48.54.54.50 ; "HTTP", case-sensitive

OBS: case-sensitive means when we have http and HTTP they are not equal. this means that HTTP will be always uppercase.

• A server SHOULD send a response version equal to the highest version
  to which the server is conformant that has a major version less than
  or equal to the one received in the request. A server MUST NOT send
  a version to which it is not conformant. A server can send a 505
  (HTTP Version Not Supported) response if it wishes, for any reason,
  to refuse service of the client's major protocol version.

• A server MAY send an HTTP/1.0 response to a request if it is known or
  suspected that the client incorrectly implements the HTTP
  specification and is incapable of correctly processing later version
  responses, such as when a client fails to parse the version number
  correctly or when an intermediary is known to blindly forward the
  HTTP-version even when it doesn't conform to the given minor version
  of the protocol. Such protocol downgrades SHOULD NOT be performed
  unless triggered by specific client attributes, such as when one or
  more of the request header fields (e.g., User-Agent) uniquely match
  the values sent by a client known to be in error.

• When an HTTP message is received with a major version number that the
  recipient implements, but a higher minor version number than what the
  recipient implements, the recipient SHOULD process the message as if
  it were in the highest minor version within that major version to
  which the recipient is conformant. A recipient can assume that a
  message with a higher minor version, when sent to a recipient that
  has not yet indicated support for that higher version, is
  sufficiently backwards-compatible to be safely processed by any
  implementation of the same major version.

TODO: Implement Request package

https://datatracker.ietf.org/doc/html/rfc2616#section-5

Follow: