Does google chrome breaks the large form (example in my case length 30000kb) before submission ? because when i analyse the network with network protocol analyser , IE doesnt break the large form , and submitts the whole form as one reqeust . but google chorme break into 2 chunks and submits , and i get error because of this .

Dani AI

Generated

Short summary and next steps — this is not a Chrome bug so much as a mismatch between how Chrome frames a large HTTPS POST and how some server/proxy stacks expect to receive it. ’s Wireshark note (“encrypted alert”) plus the fact it works through Fiddler (which terminates/re‑issues TLS) strongly point at a TLS/proxy/load‑balancer or server-side parser problem, not the browser inventing extra HTTP requests. ’s reminder about proper multipart format is correct—still, that alone won’t fix a TLS/fragmentation handling bug.

What to check first (most useful order):

  • Compare request headers Chrome actually sends (DevTools → Network) with what works through Fiddler — look for Transfer-Encoding: chunked, Content-Length, or Expect: 100-continue.
  • Check front-end components: reverse proxy, load balancer, WAF or IPS often reject unusual TLS record sizes or chunked bodies. Look at their logs around the failure time.
  • Verify server-side limits (examples commonly relevant): Nginx client_max_body_size, Apache LimitRequestBody, Tomcat maxPostSize, IIS maxAllowedContentLength. These won’t cause a TLS alert normally, but misconfigurations or buggy modules can.

Concrete debugging steps you can run:

curl -v -F "file=@bigbigfile" https://yourhost/upload
sudo tcpdump -i any -s 0 -w upload.pcap host yourhost and port 443

To see the decrypted HTTP inside the capture, have Chrome write TLS keys and load them into Wireshark:

# Linux / macOS
export SSLKEYLOGFILE=~/sslkeys.log; google-chrome &

# Windows (PowerShell)
$env:SSLKEYLOGFILE="C:\temp\sslkeys.log"; start chrome

Then point Wireshark’s TLS (SSL) key log file to that sslkeys.log.

If the capture shows multiple TLS records but a single HTTP POST, that’s normal fragmentation; the problem is a middlebox or server closing the TLS connection (hence the encrypted alert). Fixes: upgrade/patch the load balancer or TLS stack, adjust proxy/WAF settings to accept chunked/large bodies, or as a pragmatic workaround implement client-side chunked/resumable uploads so each request stays small. Contact the network/security appliance vendor if logs implicate an appliance.

Recommended Answers

All 2 Replies

WTH are you trying to submit a 30MB http request in one bit? Multipart mime requests have been with us for over a decade.

Yes i tried adding multipart mime in header . did not work !!!. but anyways , this problem only in google chrome and works fine in IE and firefox.
i used a fiddler tool during form submission from chrome , and fiddler manipulates something and send the request to server, and submission is succesful.
now i am trying analyse network packets from wireshark , i found i get "encrypted alert" message . and also the large data is split into 2 chunks . while in submission from IE there is split !!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.