Feature Request: Automatic HEAD request handling

Bắt đầu tại điểm vào đăng ký route e.GET() và so sánh với cách tiếp cận middleware.AutoHead() được đề xuất. Xem xét hành vi hiện có của router và việc đăng ký route, sau đó xác định cách xử lý HEAD tự động nên hoạt động khi không có route HEAD tường minh. Công việc được xem là hoàn tất khi các route GET phục vụ các yêu cầu HEAD với phần body của response được loại bỏ mà không thay đổi hành vi HEAD tường minh.

Currently, Echo requires explicit HEAD route registration for every GET route. Some other frameworks like Fiber, Express and Fastify handle this automatically. According to HTTP semantics, HEAD should behave identically to GET except that the response body is omitted. Automatically supporting HEAD for GET routes aligns with this expectation and reduces boilerplate.

Related: #654

Proposal

Add automatic HEAD handling for GET routes when no explicit HEAD route is registered.

Implementation Options

Option 1: Middleware approach

e := echo.New()
e.Use(middleware.AutoHead())

Pros:

• Opt-in
• No changes to core routing
• Simple implementation

Cons:

• Must be registered last in the middleware chain. Otherwise, middlewares registered after it will not execute for HEAD requests, since the middleware directly invokes the handler and bypasses the remaining chain

I've already implemented this approach, but after testing I realized the middleware ordering requirement makes it less convenient and more error-prone.

Option 2: Core integration

Auto-register HEAD routes during e.GET() calls, controlled by config :

e := echo.New()
e.AutoHead = true

Default value could remain false to avoid breaking existing behavior.

Pros:

• No middleware ordering constraints
• Slightly better performance, since re-routing is avoided

Cons:

• Requires changes to core Echo router/route registration

Questions

1. Would the Echo team be interested in this functionality?
2. If so, which implementation approach would be preferred: middleware or core integration? Would you consider a PR for either approach?