Why the fuck do I need an Accept, A content-type AND and responseType (which, by the way doesn't go with the rest of the request headers, it has to sit outside them just to fuck you up). Just so angular will stop trying to parse absolutely fucking every request as JSON?

I'm well aware my knowledge of http protocols and angulars apis's are not the best but for fuck sake. What dark book of secrets must I uncover to illuminate the strategies behind these choices?

Why, when the Accept type is text, the Content-Type is text. When the request itself is handwritten beautifully on parchment and sent via fucking carrier pigeon to the backend and returned by horse and carriage, does ANGULAR STILL TRY TO PARSE IT AS FUCKING JSON. JUST STOP.

You can get granular access using the observe option and its static mode identifiers

https://brianflove.com/2018-09-03/...

You can also write an interceptor to intermediate the response, which is what I do for protobuf payloads.

responseType isn't a header. Must be an angular thing.

Content-Type means "I'm sending you data of this type".

Accept means "For the response, I can handle data of these types" (optionally with certain priorities, e.g. if my png parser is faster than my jpeg parser I can set it at a higher priority).

@junon Yeah i'm getting there slowly but thats a helpful explanation, thanks. When you don't know much about Http headers its easy to confuse response-type (which is an angular thing) with all the rest which aren't. I guess thats why it doesn't sit in the HttpHeaders object with the rest of them.

@lorless I think that's a fair assumption :)

HTTP 101:

HTTP was a protocol ("electronic language", if you will) designed for manipulating or fetching resources (files, images, database entries, whatever) from computer A to computer B in "request/response" style - meaning, every transaction starts with a request and ends in a response.

An HTTP "message" (either a request or a response) has a prelude, headers, and then (optionally) a body (of data).

The prelude for a request is usually a method name (GET, POST, PUT, DELETE, etc.) which describes the action to perform, followed by a URI path that indicates which resource on which you want to perform it.

The prelude for a response is usually a "status" code and then some extra text that explains the code. 2xx means OK, 3xx means "look somewhere else" or "not here", 4xx means "the request was shitty" and 5xx means "the server messed up".

Headers describe the content or the nature of the request, extra "meta" parameters, etc. There are only a few standard ones, and most of them you don't ever have to touch yourself (the browser handles them for you, usually).

Content-Type describes MIME type of the content that's being sent, either as a request or a response.

Accept means "the requester can accept these types" (as I explained before).

Content-Length tells the other side how much data (in 8-bit bytes) to expect the body to be. This can be helpful for memory allocation purposes, security purposes, etc. but is generally ignored (not that you should do this, technically - always good to check).

There are a handful of caching related headers, a few for security/access control, etc. but you usually deal with them a handful of times and integrate them into a wrapper.

Why not put all of that information into the body? Or conversely, why not put all of the body information into the headers?

Because of who uses them.

The application uses the body, very plainly.

However, for things like load balancers, application firewalls, routers, proxies, etc., they don't generally care about the body of the message and only need to read a few headers to understand the "destination" or the intent of the request/response in order to transport it somewhere else, or to potentially filter it, etc.

These sorts of programs usually don't care about the /content/ of the message, but just about the information of the message itself.

For example, a load balancer might be configured to reject all body sizes (content-length) above 4 megabytes because of memory exhaustion problems. The load balancer only needs to read the beginning bit of the message to decide that, and then can forward the rest of the traffic to the application if it's OK (or send a response back if not).

hope that helps.

@junon

"2xx means OK, 3xx means "look somewhere else" or "not here", 4xx means "the request was shitty" and 5xx means "the server messed up"

Haha, this is actually gold. Thank you. I feel like im getting the ELI5 (Explain it like im 5 years old) treatment and its working wonders.

@junon It actually helps a tonne, I feel like this should be posted somewhere for posterity. Pitched at just the right level for me to understand. Thanks.

No problem :)

You're using Angular? Oh, you poor soul

@junon
Why take swags and keep guessing when I gave the actual answer?

Its a documented configuration property for httpclient, with a documented enum of values. Its not a header.

@SortOfTested I didn't know what your comment meant, I've never used angular. haha

@junon
And now OP is totally lost and on the entirely wrong path 😋

@SortOfTested I disagree, they just expressed they were new to HTTP. So I gave a crash course. I never claimed it would explain angular stuff

@SortOfTested nope, you didn't understand the problem I was having at all. junon's explanation and understanding was perfect.