Concept of URL path is supported only at application layer level?-CodePudding

I'm writing my own client and server, they are implement my own application level protocol. For transport layer TCP is used. For internet layer IPv4 is used. Nor TCP header, nor IPv4 header not contain any information about URL path. TCP header contains port, IPv4 contains IP address. Who should contain path?

So, consider this URL - 127.0.0.1:4444/location-path. 127.0.0.1 is supposed to be part of IPv4. 4444 is supposed to be part of TCP. For example, in Golang, using standard net.Dial() and net.Listen(), I can only use 127.0.0.1:4444. Using of 127.0.0.1:4444/location-path will throw an error, which is really expected because it provides support only for TCP/IP/domain name resolving, and /location-path is not part of all these three.

So, on client and server side, how I should handle /location-path in a such way that client can send requests to different locations and server can serve different locations?
Every application protocol should implement its own logic to handle /location-path?

According to RFC 1738:

url-path
    The rest of the locator consists of data specific to the
    scheme, and is known as the "url-path". It supplies the
    details of how the specified resource can be accessed. Note
    that the "/" between the host (or port) and the url-path is
    NOT part of the url-path.

The url-path syntax depends on the scheme being used, as does the
manner in which it is interpreted.

So, I can implement my own rules for url-path and how it will be interpreted by client and server? And to transfer it I can just send it as a data?

For example, I can just define rules that my own application level protocol - proto - will place url-path at first four bytes of TCP payload? So, proto://127.0.0.1:4444/path will become 127.0.0.1:4444 with TCP payload [112 97 116 104].

CodePudding user response：

The easiest way to compare this is HTTP.

A http url might look like http://example:1234/bar

A http client understands that URL. The HTTP client will (under the hood) still make a standard TCP connection to get there.

It does this by grabbing the host and port portion, and (temporarily) discard everything else. So only example and 1234 is used in that stage.

After the TCP connection is established, it will use the path part and send it as the first line.

TCP clients don't know about URLs, they know about hosts and ports. What you do with the path portion is up to you.