>The application layer should not inject error codes into the transport layer which is what HTTP is in this case.

I don't follow. What's the boundary between transport layer and application layer in a Go web app?

The Go web app is responsible for specifying both the HTTP status code and the response body.

What's the purpose of different HTTP 4xx errors if they're not supposed to come from the application?

>Do you also think that Apache/Nginx should be injecting codes into IP packets?

No, because Apache/Nginx is not responsible for populating IP datagrams, whereas Go web apps are responsible for generating the entire HTTP response.

>If your application injects codes into the HTTP layer, how on earth does the client know whether the error originated at the application or at the reverse proxy/webserver?

It can't.

What design do you have in mind where a client gets a HTTP 404 and can distinguish between the web server and the application server? Are you saying a "not found" at the application layer should return HTTP 200 and the client has to check the HTTP body for the real error code?

▲

lelanthran 2 days ago | parent [-]

> I don't follow. What's the boundary between transport layer and application layer in a Go web app?

Just because it's the same app preparing both the transport and the application, you think that it's the same layer of comms?

> Are you saying a "not found" at the application layer should return HTTP 200 and the client has to check the HTTP body for the real error code?

The "not found" is not an application level error, even if, in your backend, you mixed them all up into the same function.

▲

mtlynch 2 days ago | parent [-]

>Just because it's the same app preparing both the transport and the application, you think that it's the same layer of comms?

Yes, that's what I think.

I don't see any other way of dividing it, which is why I asked what you think the boundary is otherwise.

Again: Can you explain what you think the boundary is between the application layer and transport layer in a Go web app?

>The "not found" is not an application level error, even if, in your backend, you mixed them all up into the same function.

If the request is something like /user/detail/12345 and user 12345 doesn't exist, what should the response be?

▲

lelanthran 2 days ago | parent [-]

>> Just because it's the same app preparing both the transport and the application, you think that it's the same layer of comms?

> Yes, that's what I think.

If you don't know how communications composed of multiple layers work, I'm afraid I can't really help with that understanding in a comment section on a forum.

I mean, for example, you can use git over ssh or git over https, but no one thinks that the git communications + https (or git comms + ssh) is a single layer.

> Again: Can you explain what you think the boundary is between the application layer and transport layer in a Go web app?

A single Go web app also does SMTP and TCP[1]. Do you also think that SMTP and TCP are on the same comms layer(s) as HTTP and REST?

Many Go apps also support SSL. Does that mean it is okay for the HTTP webserver to put HTTP-specific content into the SSL layer?

---------------------

[1] Maybe you have a Go webapp that never needs to send confirmation emails, but when I last did that in Go, the Go app needed to reach into the TCP stack (specifically to set socket options) in order to make SMTP work.

	▲	aatd86 2 days ago \| parent \| next [-]
		I am interested in any answer to this > If the request is something like /user/detail/12345 and user 12345 doesn't exist, what should the response be? This is quite an interesting question. If we consider that webservers host paginated applications, the answer would be that this is indeed an application level concern and we should return a 404 since the resource is not found. SPAs without SSR may have muddled this since the application is about serving a client side application then. We could expect a 200. It is not as straightforward as it seems perhaps...
	▲	mtlynch a day ago \| parent \| prev [-]
		>If you don't know how communications composed of multiple layers work, I'm afraid I can't really help with that understanding in a comment section on a forum. I'm not asking you to explain protocol stacks, and I feel like that's obvious. I've been open to your viewpoint, and I've asked you to clarify your position. Instead you just keep mocking me and feigning surprise that I hold a pretty mainstream view. At this point, I'm left to assume you're either trolling or you have a viewpoint that can't bear scrutiny, so I'll stop engaging with you.