[Bug]: URL maximum length in E-Document Integration

[pluethi]

Describe the issue

When implementing the interface Microsoft.eServices.EDocument."E-Document Integration" to Send E-Documents we came across the issue that request URIs which are longer than 250 characters lead to an error in procedure InsertIntegrationLog of Codeunit 6132 "E-Document Log" due to the validation of the URL record field 7 of table 6127 "E-Document Integration Log" which is limited to 250 characters.

Expected behavior

The supported maximum length of the URL should be longer.

Steps to reproduce

1. Create a Codeunit which implements "E-Document Integration"
2. Implement procedure "Send" using a request URI with more than 250 characters in parameter HttpRequest
3. Error will be raised by the field validation in the subsequent call to the procedure InsertLog in codeunit 6132 "E-Document Log" due to the length of the RequestUri which is longer than 250 characters.

Additional context

The .NET System.Uri class limits the maximum length of a URI for the System.Net.Http.HttpClient to 65519 characters. Per RFC 9110 (published in June 2022) there is no fixed limit for URIs, but it is recommended to support, "at a minimum, URIs with lengths of 8000 octets in protocol elements". Given the Business Central context, we would argue for URIs limited to not more than 2048 characters as an expected limit.

As a workaround we currently update the request URI of the HttpRequest parameter before exiting the procedure as follows:

I will provide a fix for a bug

• I will provide a fix for a bug

[JesperSchulz]

Sounds fair to present a clear error message in this case. Approved.

[pluethi]

As the logging happens after the request has been sent (to an external system) it seems to me too late to raise an error. Considering that I do not see a way to raise the error earlier in the pipeline without making significant changes to the current design, as the HttpRequest object is passed by reference into the (customized) interface implementation of the Send procedure. I assume this would need a more specific scope to move forward with a PR.

As we often face (REST-style) APIs with URLs longer than 250 characters (e.g. due to Guids as entity Ids, et cetera) it would make sense (in our teams opinion) to allow for longer URL paths as a more general solution. To expand the "E-Document Integration Log" URL it would be needed to implement a new field (e.g. "Request URL" or "API URL", change all references to the "old" URL field and mark the old field for pending obsoletion. Since this is obviously a more significant change, I will also not move forward without an approval for this scope.

If we get some guidance which direction (or even a simpler solution) should be implemented, we are happy to move forward with a PR in a timely manner.

[JesperSchulz]

Please allow me to discuss internally! I will get back to you soon!

[JesperSchulz]

We agree that a 250 char limit on URLs is sub-optimal and we would be open for improvements here 😊 As you know, the maximum length of a Text field in the database is 2048 characters. Would that suffice? Or are you looking for even longer strings?

[pluethi]

As written in the original post (Additional context), our team believes that a limit of 2048 characters is an expected limit in the context of Business Central and, at best, no one will notice this limit in the future.

[JesperSchulz]

OK, needed to make sure I got that right. So if the plan is to increase the URL field from 250 to 2048, I approve! You can go ahead and make the change.
The solution you describe would be the right one! Given this is a log table, I could be tempted to ask for a breaking change exception, but it wouldn't be the "right" solution... the table is public and we hence must deprecate the old field, create a new one, copy the data, keep them in sync... Again given it's a log, you could consider if it's OK to truncate the URL and put it into the old field for backwards compatibility. By the book, the logs wouldn't support longer URLs until the old field is deprecated "removed" in 3 releases from now - but usually people cannot wait that long 😉
Anyway, looking forward to what you come up with!