Feature request: easier access to ETag in the curl CLI

[paulehoffman]

It would be useful if there was a one-step way in the curl CLI to get the ETag header from one request and be able to feed it directly to the next request, with curl using the If-None-Match header. This would probably involve two new options, and might look like:

# curl -O --save-etag my-etag-file https://myurl
# curl -O --compare-etag my-etag-file https://myurl

[bagder]

I like this idea. There are some details to think about if someone would work on implementing this. Throwing them out here!

I think it would make sense to name the options --etag-save and --etag-compare to group them and make tab-complettion etc possibly more intuitive.

In a case like the first command line that would save the etag, I would imagine that a user then also would like the command line perhaps to return a failure if it didn't actually get a proper etag back.

Would the my-etag-file also store the used URL or only the etag? Like what if the user invokes the command line with another URL in the second line, should curl still use the etag from the first invoke? If the file format would store both etag and URL the same file could be used for multiple URLs.

If --etag-compare doesn't get a 304 back, meaning that it didn't match and the site sends a new Etag, should it then update the file automatically or should we require a --etag-save even in the second command line for that?

[paulehoffman]

+1 to --etag-save and --etag-compare for naming.

If the server doesn't supply an Etag, --etag-save should still save a file, but it would be zero-length.

As for the contents of the my-etag-file:

1. Easiest: just the Etag
2. Reasonable: URI and Etag; --etag-compare gives an error when calling it with a different URI
3. Hardest but most useful: Multiple lines with URI/Etag pairs; --etag-compare gives an error when the URI is not in the files

Yes, --etag-compare should try to update my-etag-file on a new Etag, but not fail if it cannot update the file.

[patrickkh7788]

what about CURLINFO_ETAG for api support!

[bagder]

what about CURLINFO_ETAG for api support!

I just don't see the need. You can already set the header and parse response headers. I don't think we need CURLINFO_ETAG. Do you imagine it would do anything more than just extracting the header value?

[patrickkh7788]

to get ETAG and send it with If-not-match late for the same URI, the server will response 304 without body. then the client can reuse the last cached response body.

this avoid parse response headers by user.

[s-3ntinel]

Can I work on this issue? Also is this something, a first time curl contributor can actually implement? Thanks

[bagder]

@s-3ntinel Oh absolutely, please feel most welcome to grab this issue and do something with it!

I would propose that you read the comments done so far and maybe come up with a way you think makes sense and then proceed to implement that and submit a PR. Just be prepared that we might get into some discussion on how exactly the functionality should be, how what the flags should work and how they should be named etc. But we're all on the same team here so there's no ill will and nothing but good intentions driving the feedback.

If you want to, file the first PR with a [WIP]tag (for work in progress) just to signal that it isn't quite ready for merge but that you're looking for feedback and general comments on your approach.

Also, if you get stuck on implementation before you get to a PR, join the curl-library mailing list and ask questions there to the team or join the IRC channel (#curl on freenode) to get some real-time discussions.

Thanks for considering this!

[s-3ntinel]

Thanks for the info! Will try my best.