Export Website RFQ Message Length: Textarea Limits Versus Server Validation

An RFQ textarea’s minlength and maxlength attributes count UTF-16 code units and act as an immediate browser gate, while the server’s own length check is a separate responsibility that the HTML attributes do not define. This article explains the unit, when browser validation applies, why the server must count the message itself, and how to reject an over-length RFQ with a clear error instead of silently losing the buyer’s technical detail. No numeric maximum is recommended, and no conversion, ranking or customer-test outcome is claimed.

Why a browser length rule and a server length rule can disagree

An RFQ form on an export website usually gives the buyer one large box for technical requirements. That box is a multi-line plain-text editing control, intended for a sizeable amount of free-form text such as a comment on a review or feedback form, which is exactly the shape of a requirement description. The mistake is to treat the box’s length rule and the server’s length rule as one setting. They are two gates owned by two different layers, and they can disagree.

The browser gate is expressed through the minlength and maxlength attributes. The server gate is whatever the receiving endpoint does with the submitted value. The HTML attributes do not define the server’s count, and the server’s count does not automatically match the attribute’s unit. The specific divergence to watch is the counting unit. The attributes count UTF-16 code units, while the server’s count depends on its own implementation. A message that is comfortably inside the browser limit can therefore be outside the server limit, or the reverse.

The general acceptance-contract concept — what the endpoint will accept, and who owns the limit — is already covered in the drawing-upload guide for RFQ forms, so this article stays on the count mismatch rather than restating that contract. The reason the server gate cannot be skipped is not a length detail: client-side validation is bypassable and should be used for immediate feedback, while server validation is required even when the browser checks the same fields.

MDN reference

OWASP reference

What minlength and maxlength actually count

Both attributes are measured in UTF-16 code units. maxlength is the maximum string length in those units that the user can enter; if the value is not specified, the user can enter an unlimited number of characters. minlength is the minimum string length in the same unit that the user should enter.

The unit matters because UTF-16 code units are not the same as visible characters for every script. A character outside the Basic Multilingual Plane occupies more than one UTF-16 code unit, so a requirement written in such characters consumes more of the browser’s budget than a reader would guess by counting glyphs. The server’s own count is not defined by these attributes and can differ for exactly those characters.

Two edge cases decide whether the browser gate actually fires. minlength does not stop the user from removing characters so that the number entered goes past the minimum, but it does make the value entered into the textarea invalid. And even with a minlength value set, an empty textarea is still considered valid unless the required attribute is also set.

This is a hypothetical illustration, not a real customer case or a measured test. Hypothetical example: a buyer pastes a technical requirement that mixes Latin product codes with a script whose characters sit outside the Basic Multilingual Plane. The visible text looks short, but the UTF-16 count is higher than the glyph count, and the browser ceiling arrives earlier than the buyer expects.

When the browser validates, and what the buyer sees

Browser validation applies to the textarea value against minlength, maxlength and required. It is a check on the value in the control, and it runs in the browser before the form is submitted. The validity state is not invisible. Valid and invalid values of a textarea element — those within, and outside the bounds set by minlength, maxlength, or required — can be highlighted using the :valid and :invalid pseudo-classes.

For the buyer, the practical moment is the paste. A long technical requirement pasted into the box can hit the maxlength ceiling before the server is ever involved, and the buyer may not realise that part of the requirement never entered the field. This is why the browser check should be understood as immediate feedback, not as proof that the server will accept the value. Client-side validation is bypassable and is meant for immediate feedback; the server still has to validate.

Why the server must count the message itself

The server’s length count is its own responsibility. The textarea attributes do not define it, so the endpoint needs an explicit rule for the message field. For strings, the rules to enforce include length limits and the characters or structure required by the field.

There is also an ordering concern that sits before the field rule. Request size limits should be applied before buffering or parsing input, and parser limits such as maximum nesting depth should be configured. A schema check after parsing cannot protect a parser that has already exhausted resources. The general reason server validation is required even when the browser checks the same fields is already covered in the drawing-upload guide, so this section keeps to the length-specific point: the server’s count is independent of the attribute unit and must be implemented deliberately.

Rejecting an over-length RFQ without silently losing the requirement

When the message exceeds the server’s rule, the correct behaviour is to reject the request with a clear error and not continue with partially validated data. Truncating the message and storing the shortened version is the failure mode this avoids: the buyer believes the requirement was sent, and the salesperson receives an incomplete inquiry. For the server to locate the field in the submitted form data, the textarea needs a name attribute, which sets the name of the associated data point submitted to the server when the form is submitted.

The rejection should also be recorded. Log the failure and relevant metadata without secrets or full request bodies, and escape any retained untrusted values for the log format to prevent log injection.

This is a hypothetical illustration, not a real customer case or a measured test. Hypothetical example: a buyer submits a requirement that passes the browser check but exceeds the server’s own length rule. The endpoint returns a clear error naming the message field, the buyer shortens the text and resubmits, and the salesperson receives the full requirement rather than a silently shortened version.

Free-form Unicode text in an RFQ message

A technical requirement is free-form text, and it will contain punctuation, units, model codes and possibly non-Latin scripts. The server should agree on a character encoding across components and reject malformed input, while preserving legitimate punctuation and scripts in names and comments.

This is where a length rule can be implemented badly. For free-form comments, an allowlist can permit broad Unicode text while limiting its length; it need not restrict users to letters and digits. A rule that blocks punctuation or non-Latin characters to control length rejects legitimate technical text without making the field any safer. The reader-facing decision is therefore not a number. It is whether the message field’s rule is expressed as a length limit over broad Unicode text, with the server’s own count implemented deliberately, rather than as a character restriction that quietly excludes the buyer’s actual requirement.