rdmi

Have you tried, on fersen.ee, putting a header:

Access-Control-Allow-Origin: fersen.ru

?

*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.)

I wish that helped.

Only one sitemap shows up on the old console, and that’s sitemap.xml — I am reluctant to remove that for the same reason I’m reluctant to change the plugin code.

If anything, changing the plugin code seems safer. (The hope, there, would be that a few 404s or 301 redirects and google would update their dataset to match. If that worked, I wouldn’t have to mess with google search console dysfunctionality.)

That said… it looks like the v3 search console api has a webmasters.sitemaps.delete method, which I can use…

• This reply was modified 5 years, 8 months ago by rdmi. Reason: found what looks like a working approach

(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.

I have run into a similar issue.

However, I do not understand the details. It’s almost like some posts become “broken” and others work ok.

https://status.brightcove.com/ indicates a major brightcove outage.

Once they have their api working again, we should probably ask them for an update to their plugin so it doesn’t take out all of wordpress editing when they have problems.