msimonborg
I thought about opening an issue for this question in the Req repo, but I think it’s more an issue with my HTTP knowledge. I’m hoping someone here can point me in the right direction.
I have an application that builds a database from an external data source. The data is available in .zip files and downloaded by performing get requests to known URLs. I am performing the requests like this
Req.get!(url, raw: true, output: file_path)
Occasionally I want to rebuild the database in development. Lately I’ve been getting exceptions during some attempts to rebuild when the files cannot be unzipped, due to invalid file contents {:error, :einval}. I traced the error to the request response, which is returning a status 304 "not modified" and a body "". The empty body contents are being written to the output file path, causing the unzip error downstream.
%Req.Response{
body: "",
headers: [
{"content-type", "application/zip"},
{"last-modified", "Wed, 22 Sep 2021 19:48:44 GMT"},
{"cache-control", "private, max-age=169126"},
{"date", "Sun, 03 Jul 2022 15:21:43 GMT"},
{"connection", "keep-alive"}
],
private: %{},
status: 304
}
Is there any way to get around the 304, or to force my way to a 200 with the desired response body? Or is there just no workaround as long as I’m requesting the same contents from the same IP within the server’s cool-down period?
Thanks in advance for any suggestions.
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #ai
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
al2o3cr
Do you have any other global / default config set for
Req? The only way a server should be replying with an HTTP 304 is if the request has anIf-Modified-Sinceheader, and the only way that happens in default Req is withcache: trueset - which should also handle the 304msimonborg
Thanks, I had a similar thought after doing more digging, but I’m not setting any config for
Reqanywhere, or passing any extra opts to that request.msimonborg
Update to this, I tried hitting the same url in
ReqandHTTPoison, Req seems to be caching somehow under the hood while HTTPoison returns the desired response.This was done in a fresh iex session with
Mix.install([{:httpoison, "~> 1.8"}, {:req, "~> 0.3"}]), so there are no global config overrides.I’ll probably bring this to the
Reqissue tracker from here.wojtekmach
Yeah, not sure what’s going on. Just to get it out of the way, you’re sure you’re not using
Req.default_options(cache: true)anywhere, e.g. in your .iex.exs and such? Could you run the following?and paste the results?
msimonborg
Thanks for looking into this, I haven’t set any config options in .iex.exs or in the application config, I grep’d for
Reqin the app repo and there are only two references, bothReq.get!calls.Output:
wojtekmach
Everything looks correct. Sorry, not sure what’s going on. I tried reproducing it but it works well here. If you can come up with steps to reproduce, I’m happy to try them out.
msimonborg
Ok, this should reproduce. I had to find another file on that server that was returning 200 for me. This is one of the smaller payloads too, 669kb.
I am noticing that in the response headers when using Req (for both statuses 200 and 304) there is this for
"cache-control":While with HTTPoison:
max_ageis counting down in seconds on each request.msimonborg
I realized I should try 50 requests with HTTPoison too:
wojtekmach
OK, I was able to reproduce it with this script:
interestingly, for me, it always either printer 200,200,… OR 304,304,… never one or the other (though I didn’t run it for long)
Req by default sets accept-encoding with gzip and others. Maybe that is confusing the server? You can turn it off like this:
compressed: false.I have tried this a few times and always kept getting 200s:
msimonborg
Incredible, this is working for me now:
It returns 200 with the expected binary response body that writes a valid .zip file, and the
"cache-control"response header is now{"cache-control", "private"}.Thanks so much!