Issue Description
When using echo for a web application sending HTML and receiving MIMEApplicationForm POST requests, it seems very difficult / impossible to show helpful validation error messages to the user, when using echo.context.bind().
For any string data coming from the MIMEApplicationForm submit which cannot be converted to the target type in the "DTO" struct provided, echo.context.bind() returns a generic error that gives no information about which struct/form field failed validation.
This makes it very difficult or impossible to render a helpful message to the user like "The number field should contain an integer". when the failed form is re-rendered in the browser.
This issue is also discussed here:
https://stackoverflow.com/a/77712569/1087626
The issue apparently does not exist when dealing with JSON data rather than MIMEApplicationForm
Checklist
Expected behaviour
For the error returned from context.bind() to return some information about which field failed type conversion
Actual behaviour
The error returned from context.bind() contains no information about the form field which failed type conversion.
Steps to reproduce
server as below, then POST a non-integer to be bound into an integer field
$ curl localhost:8080/submit -d"number=10a"
code=400, message=strconv.ParseInt: parsing "10a": invalid syntax, internal=strconv.ParseInt: parsing "10a": invalid syntax
Working code to debug
package main
import (
"fmt"
"net/http"
"github.com/labstack/echo/v4"
)
type DTO struct {
Number int `form:"number"`
}
func main() {
e := echo.New()
e.POST("/submit", func(c echo.Context) error {
dto := DTO{}
if err := c.Bind(&dto); err != nil {
return c.String(http.StatusBadRequest, err.Error() + "\n")
}
return c.String(http.StatusOK, fmt.Sprint(dto) + "\n")
})
addr := "127.0.0.1:8080"
e.Logger.Fatal(e.Start(addr))
}The following diff shows that the desired "fieldname" information is available in the relevant part of bind.go and could return that info with the error:
--- /home/oliver/bind.go 2024-04-24 17:01:48.429244184 +0100
+++ /home/oliver/go/pkg/mod/github.com/labstack/echo/v4@v4.12.0/bind.go 2024-04-24 17:09:46.881545243 +0100
@@ -263,7 +263,7 @@
}
if err := setWithProperType(structFieldKind, inputValue[0], structField); err != nil {
- return err
+ return fmt.Errorf("%s: %w", inputFieldName, err)
}
}
return nil
This may not be the preferred way to fix it (and would require some string parsing of the error message to get the desired info) but it shows a proof of concept solution.
The result with the above fix is:
$ curl localhost:8080/submit -d"number=10a"
code=400, message=number: strconv.ParseInt: parsing "10a": invalid syntax, internal=number: strconv.ParseInt: parsing "10a": invalid syntax
Version/commit
v4.12
Issue Description
When using echo for a web application sending HTML and receiving MIMEApplicationForm POST requests, it seems very difficult / impossible to show helpful validation error messages to the user, when using
echo.context.bind().For any string data coming from the MIMEApplicationForm submit which cannot be converted to the target type in the "DTO" struct provided,
echo.context.bind()returns a generic error that gives no information about which struct/form field failed validation.This makes it very difficult or impossible to render a helpful message to the user like "The
numberfield should contain an integer". when the failed form is re-rendered in the browser.This issue is also discussed here:
https://stackoverflow.com/a/77712569/1087626
The issue apparently does not exist when dealing with JSON data rather than MIMEApplicationForm
Checklist
Expected behaviour
For the error returned from
context.bind()to return some information about which field failed type conversionActual behaviour
The error returned from
context.bind()contains no information about the form field which failed type conversion.Steps to reproduce
Working code to debug
The following diff shows that the desired "fieldname" information is available in the relevant part of
bind.goand could return that info with the error:This may not be the preferred way to fix it (and would require some string parsing of the error message to get the desired info) but it shows a proof of concept solution.
The result with the above fix is:
Version/commit
v4.12