• In the current version of this plugin (2.0.1), my media uploads to S3 using this plugin add an “Expires” metadata element to the uploaded files, with a date one year in the future.

    Meanwhile https://aws.amazon.com/blogs/aws/amazon-s3-multi-object-deletion/ suggests that under some conditions, S3 will automatically delete the files for me based on this expires header.

    But, I would rather not have my wordpress media automatically deleted after 1 year, even if someone else starts using expires rules in some other context.

    So, question:

    How do I prevent this expires metadata from being set on my uploads?

    (Also, is there a good way of removing the metadata (but not the uploaded files) for existing uploads? I might be able to figure this out myself, but also I might overlook the best way to do it.)

Viewing 3 replies - 1 through 3 (of 3 total)
  • Thread Starter rdmi

    (@rdmi)

    (Thinking about this, the intent was probably to generate an Expires: http header, but that wouldn’t work, either, because the expire time is one year from when the attachment was generated – after a year, this would be a time in the past. It’s perhaps unfortunate that AWS assigned a different [but technically non-conflicting] significance to this header.)

    (Anyways, it’s likely to become a problem, which is why I’d like it gone.)

    • This reply was modified 5 years, 9 months ago by rdmi.
    Plugin Contributor ianmjones

    (@ianmjones)

    That multi-delete stuff isn’t automatic, you’d need to set it up in S3 or via some tool, so I have a couple of questions…

    Q1: Why are you going to run multi-delete on the bucket key path where you know there are objects controlled by WP Offload Media?

    Q2: A quick scan of the doc you linked and its related docs didn’t give me the impression that you could use the Expires header, could you direct link to where you saw that? I probably just missed it, I’m only a couple of sips of coffee into my day.

    If you still want objects offloaded by WP Offload Media to not have the Expires header (which is only there for historical reasons as most browsers use the better Cache-Control header now) you can use the as3cf_object_meta filter and unset the $args['Expires'] array element.

    https://github.com/deliciousbrains/wp-amazon-s3-and-cloudfront-tweaks/blob/cb7c645d84969d58b43dd43b918c6c5c75218099/amazon-s3-and-cloudfront-tweaks.php#L368

    Thread Starter rdmi

    (@rdmi)

    *I* am not going to set up multi-delete in s3.

    However, I am not the only person involved here, and people do not always think through the consequences of their design decisions. (Otherwise, why would we have an Expires header on all files which, after one year, will always be in the past for every delivered image?)

    That said,

    (1) that as3cf_object_meta filter does look like it would be the way to go here, for preventing the Expires header from appearing on future uploads. Thanks for pointing that out – and I feel like I should have noticed it myself.

    (2) My memory tells me that that blog post used to explicitly mention the Expires header. It looks shorter now… But, also, looking at https://docs.aws.amazon.com/AmazonS3/latest/dev/intro-lifecycle-rules.html#w191aac19c23c15c23c24 I am now seeing that it’s “Expiration” instead. (Maybe someone noticed the conflicting interpretations for Expires, updated the spec and someone edited the blog post?)

    (3) None of this addresses removing bogus Expires headers:

    Even if they don’t trigger multi-delete, I am not sure I want to rely on browsers always ignoring that header.

    (Thanks for the response, I think you’ve moved me in the right direction here.)

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘S3 Expires metadata’ is closed to new replies.