Large document transfer

How it works

The content is still a document. The door is a link or a portal. Page count and hash both matter. A 2 GB PDF can be valid and still time out a previewer. Offer a download, not only an in-browser view.

A 1.6 GB scanned discovery set goes by expiring link. The firm's previewer gives up at 200 MB. The download finishes and the hash matches. They review in a local viewer. The ticket looked failed in the preview pane and was not.

How it differs

Large document transfer is not large video. Preview tools differ. The resume and expiry rules are the same.

Splitting into volumes without an index makes page cites impossible. Number the volumes in the delivery note.

OCR layers inflate size. Say whether the PDF is image-only or searchable so the recipient does not redo OCR.

On the ticket

• The practical close is a log line: time, actor, byte count, result.
• Without that line the transfer is a story.
• With it, the next person can see whether this door did what the ticket claimed.
• If the path is shared, say so in the partner profile so a later change does not silently pick a different limit, key, or region.
• On a real ticket, write down the door, the byte count, and the clock.
• For large document transfer, that means naming the host or bucket, the expected size, and the time the other side must have a complete file.
• A progress bar is not that record.
• A 200 response that arrives before the complete call is not that record.
• If a retry is allowed, say how many and whether it resumes.
• If a person must approve the send, name the person.
• Partners who receive large document transfer files should match on hash or size before they import.
• A same-length corrupt file passes a size check and fails a hash.
• Keep the published hash off the only channel an attacker can edit, or treat it as a corruption check rather than a substitution check.
• When the path changes, new key, new region, new cap, update the profile the same day so the next run does not use a stale limit.