You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use case:
A users wants to get a hint if the network she typed into the search field has an obvious typo regarding the CIDR format to be able to correct the search.
Examples:
194.94.208..5/16
2001:638:::0/24
technical side
What happens in current fody v0.4.3-dev is that the frontend estimates if we have a cidr (by estimating country-code and domain name first) and then sends the request to the backend. The backend uses the postgresql query and postgresql will do the typecast to the cidr type and throw a DataError if this fails. This error is already transfert to the client (https code 400) returning the json string {"reason": "DataError, probably not in cidr style."}.
Because the real test happens in the database backend, a client side test always has the danger of not being identical to the postgresql check. So it seems to be a good solution to bring the backend error code up to the front and make it visible. However it would make sense to also have a client side check that works while the user is typing.
The text was updated successfully, but these errors were encountered:
Use case:
A users wants to get a hint if the network she typed into the search field has an obvious typo regarding the CIDR format to be able to correct the search.
Examples:
194.94.208..5/16
2001:638:::0/24
technical side
What happens in current fody v0.4.3-dev is that the frontend estimates if we have a cidr (by estimating country-code and domain name first) and then sends the request to the backend. The backend uses the postgresql query and postgresql will do the typecast to the cidr type and throw a DataError if this fails. This error is already transfert to the client (https code 400) returning the json string
{"reason": "DataError, probably not in cidr style."}
.Because the real test happens in the database backend, a client side test always has the danger of not being identical to the postgresql check. So it seems to be a good solution to bring the backend error code up to the front and make it visible. However it would make sense to also have a client side check that works while the user is typing.
The text was updated successfully, but these errors were encountered: