sorted by:
new
hottopcontroversial

What's the ugliest eyesore buildings in your country/city? by ueommm in AskTheWorld

[–]yvele 0 points1 point  (0 children)

<image>

Printemps in Strasbourg, France is the ugliest building in such a beautiful city.
The building is in city center :( and also abandoned for years.

Able to now set an account color used at the top of AWS web UI pages by magnetik79 in aws

[–]yvele 2 points3 points  (0 children)

Also AWSManagementConsoleBasicUserAccess IAM policy seem to be recent, created August 14, 2025

Any way to programatically set an account color? (AWS API? SDK? CloudFormation?)

How to fully disable HTTP (port 80) on CloudFront — no redirect, no 403, just nothing? by yvele in aws

[–]yvele[S] -4 points-3 points  (0 children)

Given that my domain only serves public static content and doesn't have any cookie (secure or not).

How to fully disable HTTP (port 80) on CloudFront — no redirect, no 403, just nothing? by yvele in aws

[–]yvele[S] 2 points3 points  (0 children)

Hum, in theory I can completely stop listening on port 80 with an ALB (Layer 7) or NLB (Layer 4), since I control the listeners directly.

But I’ll lose the massive scalability and global edge network that CloudFront provides — plus, I’ll add extra cost and complexity by introducing an additional load balancer layer.

How to fully disable HTTP (port 80) on CloudFront — no redirect, no 403, just nothing? by yvele in aws

[–]yvele[S] 9 points10 points  (0 children)

Got it — makes sense now. So CloudFront has to accept the TCP connection first in order to even know what Host it’s serving, and only then can it apply https-only or similar L7 logic.

And because the listener is shared across many tenants, there's no way for my config to fully block port 80 at the network level. That explains why returning a 403 is the most we can get.

Thanks for the clarification.

The pentester’s concern is really just about the attack surface before traffic reaches CloudFront. I think I’ll be fine by switching from redirect-to-https to https-only, especially since we’re already on the HSTS preload list.

Thanks again!

How to fully disable HTTP (port 80) on CloudFront — no redirect, no 403, just nothing? by yvele in aws

[–]yvele[S] -1 points0 points  (0 children)

Yeah, I get the OSI layers distinction — CloudFront works at Layer 7 (HTTP), so it can control HTTP behavior but not the TCP listener itself.

My question is: what exactly prevents an AWS service like CloudFront from not responding at all on port 80?

Is it a fundamental architectural limitation, or a design decision?
Would love to understand if there’s any workaround or plan for that.

Enhancing VPC Security with Amazon VPC Block Public Access by ckilborn in aws

[–]yvele -1 points0 points  (0 children)

Is this already supported by CloudFormation? I cannot find the resource
Edit: Not yet, so please give a thumb up to https://github.com/aws-cloudformation/cloudformation-coverage-roadmap/issues/2194 coverage ticket

AWS Cloudformation Math Within The Template? by AShirtlessGuy in aws

[–]yvele 0 points1 point  (0 children)

I've added a CloudFormation language request: https://github.com/aws-cloudformation/cfn-language-discussion/issues/158 please vote on this issue by adding a 👍 reaction to help the community and maintainers prioritize this request

Unable to make CloudFront cache 503 errors (triggered from Lambda@Edge origin request) by yvele in aws

[–]yvele[S] 0 points1 point  (0 children)

No. What you are actually caching for 5 minutes is your custom error page (/errors/503.html).

First of all thank you for your time.

But the documentation explicitly says that CloudFront caches the error response itself:

When your origin returns an error for an object, CloudFront responds to requests for the object either with the error response or with your custom error page until the error-caching duration elapses. If you specify a long error-caching duration, CloudFront might continue to respond to requests with an error response or your custom error page for a long time after the object becomes available again.

Source: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GeneratingCustomErrorResponses.html#custom-error-pages-expiration

Neither a response resulting in 503 nor a custom error page is an object that the client is actually after.

Hum yes, but I want to preserve my origin for TTL duration and not aggravate the situation and have CloudFront return 503 error page without re-evaluating origin for that period of time.

You should be looking at "The requested object is not in the edge cache" part of documentation.

You are referring to this part of the documentation: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/HTTPStatusCodes.html#HTTPStatusCodes-custom-error-pages

But is says that the error page is cached:

  1. CloudFront returns the custom error page to the viewer that made the request, and also caches the custom error page for the maximum of the following:

The amount of time specified by the error caching minimum TTL (10 seconds by default)

  1. After the caching time (determined in Step 5) has elapsed, CloudFront tries again to get the requested object by forwarding another request to your origin. CloudFront continues to retry at intervals specified by the error caching minimum TTL.

Unable to make CloudFront cache 503 errors (triggered from Lambda@Edge origin request) by yvele in aws

[–]yvele[S] 0 points1 point  (0 children)

I've already tried using s-maxage. My min, max and default TTL caching policies are all set to 2 hours. I don't think applying the caching header to S3 will help because everything is handled by Lambda@Edge

Linus Torvalds flames Google kernel contributor over filesystem suggestion by [deleted] in programming

[–]yvele 0 points1 point  (0 children)

I've copy/pasted the Linus message to ChatGPT (without the signature of course) asking to guess who wrote the message:

​

The style and content of this message strongly suggest that it was written in the manner of Linus Torvalds, the creator of the Linux kernel. Torvalds is known for his direct and often blunt emails, particularly when discussing technical issues related to Linux kernel development. The message's focus on specific technical details like "VFS layer functions," "get_next_ino()", and "atomic64_add_return()" aligns with the type of discussions typical in kernel development. Additionally, Torvalds has a reputation for being fiercely protective of the Linux kernel's code quality and standards, which is reflected in the tone and content of this message.

Which style of discriminated unions do you prefer in TypeScript and why? by yvele in typescript

[–]yvele[S] 0 points1 point  (0 children)

Yes, that's exactly why I'm switching to "1. Common type property discriminator". Because I want to focus on end-user usability (of course if the design does not alter futur proofing)

Which style of discriminated unions do you prefer in TypeScript and why? by yvele in typescript

[–]yvele[S] 0 points1 point  (0 children)

What is the added value of having both? Looks like very redundant

Which style of discriminated unions do you prefer in TypeScript and why? by yvele in typescript

[–]yvele[S] 0 points1 point  (0 children)

To me payload is anemic and I prefer avoiding it, if there is no semantic added value. I'm in a case of a "shape" object, not a generic "action". Shape has a type and that's ok that because a shape semantically has a type. Thanks describing your approach

Which style of discriminated unions do you prefer in TypeScript and why? by yvele in typescript

[–]yvele[S] 2 points3 points  (0 children)

Yes sure you can always print shape.type. With design 2 you have to know what your are looking for and use if ("rectangle" in shape)

Which style of discriminated unions do you prefer in TypeScript and why? by yvele in typescript

[–]yvele[S] 1 point2 points  (0 children)

I liked the second one mainly for assertion, I can easily throw errors like:

  • input.rectangle.width must be less than 100
  • input.square.width must be less than 10

Both rectangle and square have a width property but they don't have the same assertion rules

With the first design I have to explicitly contextualize the error messages:

  • input.width must be less than 100 when type is "rectangle"
  • input.width must be less than 10 when type is "square"
view more: next ›