> Potentially bad keyword in body, potentially bad keyword in title, potentially bad keyword in username ---------- Potentially bad keyword in body - Position 0-12: evolpick.com Potentially bad keyword in title - Position 0-12: evolpick.com Potentially bad keyword in username - Position 0-12: evolpick.com
> Potentially bad asn for hostname in body, potentially bad asn for hostname in title, potentially bad ns for domain in body, potentially bad ns for domain in title, potentially bad keyword in body, potentially bad keyword in title, potentially bad keyword in username ---------- Potentially bad asn for hostname in body - snsinsider.com address 160.153.0.182 in ASN 209242 Potentially bad asn for hostname in title - snsinsider.com address 160.153.0.182 in ASN 209242 Potentially bad keyword in body - Position 0-14: snsinsider.com
@Makyen The regex contains an unescaped ".", which should be "\." in most cases. Append -force to the command word(s) if you really want to add the pattern you provided.
@Makyen That pattern looks like it's already caught by Bad keyword in body and Bad keyword in answer Append -force to the command word(s) if you really want to add the pattern you provided.
Hey, I just wanted to give everyone a heads-up, but later this week, we will be moving our API behind our CDN. We don't anticipate this causing any issues, but we wanted to let you all know in case something funky started happening on your end. Feel free to give me a ping if this disrupts anything with Charcoal.
Post 2: That does not look like a valid post URL. Post 3: That does not look like a valid post URL.
@GeneralGrievance You can execute the !!/report command again in 18 seconds. To avoid one user sending lots of reports in a few commands and slowing SmokeDetector down due to rate-limiting, you have to wait 30 seconds after you've reported multiple posts in one go.
@SpencerG What are the goals and intent behind doing so? CDNs generally handle DDOS protection and provide relief from repetitive requests, as are seen in page views from pages which change relatively rarely (i.e., where the response doesn't change). While it's possible that there are such requests appearing on the SE API, I'd expect that the vast majority of requests are not repetitive (and making rapid repetitive requests is, in fact, stated as not permitted). Thus, it's unclear to me how much benefit you'll really gain from using a CDN compared to the potential degradation in performance (and the near-inevitable additional rejections of some valid requests).
Specifically:
3
What additional rate limiting is being imposed by the CDN (including both returning errors and returning responses cached by the CDN)? If it's implementing a new cache, how long are responses going to be cached (i.e., how long must a requestor wait between identical requests to get new data)? Are only identical requests cached?
SD, currently, accesses the questions endpoint for SO (and we intend to do so for all sites) to get recently active questions with semantically identical requests more rapidly than the strictly permitted once per minute. Making these requests substantially more rapidly than 1/minute to get new, updated data is something we rely upon, and such requests do produce updated responses.
Is making such requests going to end up resulting in either A) the CDN rate limiting the request, or B) the CDN returning a cached identical response (even though such request currently returns updated/different data)?
What new types of responses will be seen (e.g., what new types of error responses and/or rate-limit responses)? The SE API currently provides a variety of different responses which indicate rate limiting. Knowing any new/changed responses would be helpful.
Are accesses to the SE API going to be counted within the rate-limit bucket which is used to limit requests to the main sites?
Are accesses to the SE API going to be counted within the rate-limit bucket which is used to limit requests to the chat sites?
Currently, the chat sites are separately rate limited from the main sites. There were major problems when chat was temporarily moved under the same bucket as the main sites a few years ago. If SE API accesses will be counted in the same rate limiting that's used on the main sites or chat sites, there will be problems, which will primarily end up with many power users hitting the global rate limits and being locked out of the sites.
@Makyen When this was originally explained to me, it was under the premise that its better for API stability and better protection against DDOS attacks.
For your other question those are a bit more technical than the ones I had initially so let me take those back to the team handling it to get more specific answers.
@Makyen So on goals, we are doing this to better align all of our applications, it ultimately helps us simplify our overall configuration and the plan is eventually to move everything behind the CDN.
@Makyen For additional rate limiting, the initial rollout will not include any new rate limiters; only existing ones will continue to be in place. However, the CDN would be the source of the 429 instead of the app.
@Makyen We are not introducing any new rate limiters so the behavior should in theory be the same. We are open to creating a specific bypass for SD though.
@Makyen API requests will not be cached, dev told me to see the previous answer on rate limiting with that too.
@Makyen Besides 429 for rate limiting, there could be a 403 if Cloudflare detects a DDoS attack. Another possible scenario that happens on the main site is we also generally require a user agent to be sent for all requests. If no UA is present, a 403 is returned.
@Makyen Currently api.stackexchange.com has its own rate limit bucket.
@Makyen No.
@Makyen This won't affect our current migration, but we can keep an eye on it.
Hopefully that clears your questions up. Let me know if it doesn't or it confuses things and I can poke the devs some more.
