An Italian engineering supplier sends a large design package through a customer's portal. The browser reaches ninety-eight percent, the office connection drops and the application returns to an empty upload form. The supplier tries again, then emails a transfer link because the portal cannot be trusted.
The buyer now has the same package arriving through two channels, possibly with two different revisions. A feature intended to organise project evidence has created more uncertainty than the shared mailbox it replaced.
Resumable uploads are a practical modern-web capability, especially as customer portals handle CAD, video, scans and complex document bundles. The real product is not a progress bar. It is an understandable path from selected local file to verified project material.
Give the upload its own identity
Treat an upload as a durable operation associated with an authorised user, project and intended document revision. The file name alone is a weak identifier: customers reuse names, rename files and accidentally select a different revision after an interruption.
Record the expected size and the integrity information appropriate to the chosen protocol. On resume, establish that the client is continuing the intended file. If the browser cannot recover access to the local file, ask the user to select it again with a clear explanation instead of pretending recovery is automatic.
The interface should show the project and revision destination throughout the transfer. A perfect upload to the wrong customer workspace is still a product failure.
Choose a transfer protocol with explicit recovery behaviour
The tus protocol defines resumable transfer behaviour through upload offsets and related operations. Its extensions cover capabilities such as expiration and checksums; support must be negotiated rather than assumed. This provides a clearer basis for implementation than inventing an informal sequence of chunk requests. tus resumable upload specification
Object storage can offer multipart upload mechanisms with independent parts and a final completion operation. Amazon S3's documentation explains the multipart process and supported integrity checks. A browser portal still needs application-level orchestration, permissions and recovery around those storage operations. Amazon S3 multipart upload overview
The choice depends on deployment, file sizes, operational ownership and client requirements. A supplier should explain the trade-off using your actual workflow rather than choose a library solely because its demo looks polished.
Progress is not the same as completion
A browser can finish sending bytes before the server has assembled and verified the final object. The completion stage can fail or take time. Keep uploading, finalising, checking and ready states distinct so the customer knows whether it is safe to close the page.
For S3 integrations, the completion API has specific response and error behaviour, and an ETag is not always an MD5 digest of the object. Use the provider's supported checksum semantics instead of making an assumption from the shape of a returned string. S3 completion API
Define a way to retrieve the result after the browser loses the final response. The user should be able to return to the project and discover whether the package completed, rather than uploading a duplicate because the last screen was ambiguous.
Put quarantine between storage and distribution
Files supplied by external users should not automatically become trusted downloads for everyone in the project. Define the checks required by your policy: allowed types, size limits, malware scanning, archive handling and any domain-specific validation.
Keep unapproved material separate from the normal release path. Download permission should depend on the verified application state, not merely knowledge of an object URL. A failed or timed-out scan must leave a visible unresolved state rather than quietly publish the file.
Be realistic about scanning. A successful scan is one control, not a guarantee that any file is harmless. Very large archives, password-protected content and specialised design formats may need explicit handling rules and an escalation route.
Preserve revision meaning after the transfer
The engineering supplier may submit a corrected package while the earlier package is still being reviewed. Decide whether that creates a new revision, replaces an unsubmitted draft or requires approval to supersede a released document. Do not let storage overwrite behaviour decide the business policy accidentally.
Make downstream references stable. A reviewer commenting on revision two should not see revision three appear under the same link without an explanation. Keep the original submission identity and clearly show which revision is currently accepted for work.
Our supplier document portal guide discusses ownership after receipt. The article on customer portal security provides the wider access-control questions.
Account for abandoned uploads and expired access
Incomplete transfers consume storage and operational attention. Define an expiry policy, show it to users and clean abandoned state safely. A cleanup task must distinguish an active slow transfer from a genuinely abandoned one.
Authorisation may change during a long upload. Recheck the relevant permission before final acceptance. If the project is closed or the user loses access, the portal should explain the outcome without exposing the file to an unauthorised audience.
Temporary upload credentials should have limited scope and lifetime. If a valid transfer outlasts them, the application needs a controlled renewal path tied to the same upload operation. Restarting the entire file should be the exception, not the routine response to an expired credential.
Test the unpleasant parts before inviting customers
A meaningful pilot uses the expected file sizes and representative networks. Interrupt the connection near completion, close and reopen the tab, retry a finalisation request and attempt to resume with a different local file. Check that the system neither loses accepted progress nor accepts the wrong revision.
Also test a scan outage, a rejected file, revoked project access and an abandoned transfer. Support should be able to explain each result from an operation reference without asking the customer to email the sensitive package for investigation.
Measure successful completion rate, repeated bytes transferred, time spent waiting after upload and duplicate submissions. These are concrete indicators of whether the portal improves the customer's working day.
To review the people behind a proposed build, explore Anis Khalef's selected software work alongside a discussion of your own requirements. Portfolio examples are a starting point for that conversation, not evidence that your particular upload architecture has already been implemented.
TuniCyberLabs develops custom customer portals and business software. Discuss a large-file portal pilot with a representative package, its approval journey and the connection failures your customers encounter.