Mapping request in a reverse proxy

[brazen tundra]

Hello, I'm starting the Caching Proxy back-end project. This is my first time implementing a reverse proxy server and I'm looking for some clarifications:
Since the Caching Proxy will be forwarding requests to the server or responding with the cached response it had, what will be the mapping properties of the response? I thought of the http method and the url but not sure if it is enough because the request headers can change the content of the response.
I'm looking forward for your help guys and thanks in advance 🙌 .

[cunning laurel]

I have not done any roadmaps, so I am unsure if I understand your question and the exercise properly. However, I would not write something from scratch. Instead, I would configure a common proxy server, such as NGINX, to perform caching.
https://docs.nginx.com/nginx/admin-guide/content-cache/content-caching/
I think it's more likely you'll need to configure a product like NGINX instead of writing something from scratch in the real world.
Good luck 🍀

[brazen tundra]

Thank you for your response. The thing is that it's one of the roadmap.sh intermediate level projects, you will find the link at the end of the message.
I'm not looking for a reverse proxy for personal use instead, I want to implement it as described in the project description. My issue is the following : since the cache is a key-value store, that means each key map to a value (the response in our case). What can be the reverse proxy cache key? Since using only the http method and the url (using a hash table) might not be enough because the request headers can modify a response.

Project: https://roadmap.sh/projects/caching-server

[cunning laurel]

Thanks for the link. It makes more sense.
The following are just my guesses because I don't know the intent of the exercise's author.

I think you may be overthinking the exercise.

Since using only the http method and the url (using a hash table) might not be enough because the request headers can modify a response.
Yes, that is true. However, I think the intent is to learn and understand caching with HTTP requests, responses, and headers. I don't think the intent is to build a full-fledged proxy server that can handle all possible request combinations, e.g., all possible combinations of HTTP headers.

Therefore, if I were working on this exercise, I would work towards getting the reverse proxy work for GET requests and call it good enough to move on. Even NGINX supports only the GET and HEAD methods by default: https://docs.nginx.com/nginx/admin-guide/content-cache/content-caching/#specifying-which-requests-to-cache

Kudos to you for making the extra effort. Just be careful not to spend too much time on a singular concept. The 80/20 rule (https://www.investopedia.com/terms/1/80-20-rule.asp) helps me move on and learn a wider breadth of concepts in a shorter amount of time.

Some additional considerations:
If you really want to handle the other request headers, just append or hash it into the key. You don't have to add every request header; you can just add the ones you think are most important.
I think supporting GET (and possibly HEAD) will provide the majority of the benefits for a typical caching server and serve the intent of the exercise.
I still think learning to use NGINX is more beneficial than building out a simple caching server from scratch.

• the knowledge of NGINX can be carried forward and used in the future
• troubleshooting when NGINX fails will provide the learning of HTTP requests, responses, and headers
  You might want to use the PATH instead of the URL as the cache key

Good luck 🍀 and I hope that helps 🤞

[brazen tundra]

@cunning laurel thank you very much for the clarifications and recommendations. I'll implement it by caching the get and head requests using the method and the path as mapping properties.
I'll use NGINX to get more knowledge about it.
I've read the article about 80/20 and it really change the way I approach learning a new concept.
I'll send the link when I'll be done if you don't mind for a review.
Again thank you for your contribution.