Thank you very much James :)

On Thu, Oct 29, 2020 at 12:30 PM James Smith <j...@sanger.ac.uk> wrote:

> Not sure about tuning the network – that is out of my skill set – I am
> lucky at work to have a 1G connection to my desk so these sort of uploads
> are not an issue. From home I only have around 18M so it is noticeable how
> long uploads take. You may want to look to see if you have intermediate
> hosts on your network – are you going through a transparent proxy?
>
> If the user is using a VPN there is often a large overhead than you see on
> the local network – not just the “distance” he is away – but whatever
> security layer the VPN adds, and whether content goes through multiple
> different nodes to get to you. We have noticed quite large differences with
> users going through VPNs having major issues. And remember that remotely
> many users will be using asymmetric connections – download is fast, upload
> is usually throttled to between 10 and 25% of the download speed.
>
> James
>
> *From:* eric tse <hfe...@gmail.com>
> *Sent:* 29 October 2020 19:16
> *To:* users@httpd.apache.org
> *Subject:* Re: [users@httpd] Bad Gateway with large file upload [EXT]
>
>
>
> Good afternoon James
>
>
>
> Thank you very much for your help.
>
> We are inside a working organization network.
>
> The client is using VPN.
>
>
>
> I don't know if you guys have a little bit more extra tips/directions to
> tune the enterprise network,
>
> if not, it is all okay for now.
>
>
>
> Thank you very much for your help.
>
>
>
> Thanks and regards
> Eric
>
>
>
>
>
>
>
> On Thu, Oct 29, 2020 at 12:03 PM James Smith <j...@sanger.ac.uk> wrote:
>
> Is your test over a local network or over the internet. If the latter
> there is little you can do.
>
> HTTP upload was never really designed for large files like this. That’s
> why more languages/frameworks put a limit on the size of uploads. And these
> are usually in the 5-10M size.
>
> There are much better ways of transferring large files in web-browsers
> nowadays using clever JavaScript which slices the file and a script which
> stitches the parts back together at your end – transfers are smaller and
> avoids time outs. Can also parallelize them if required.
>
> James
>
>
>
> *From:* eric tse <hfe...@gmail.com>
> *Sent:* 29 October 2020 18:15
> *To:* users@httpd.apache.org
> *Subject:* Re: [users@httpd] Bad Gateway with large file upload [EXT]
>
>
>
> Hi community,
>
>
>
> Thank you for your valuable hint again.
>
>
>
> Can we tune something from chrome?
>
> that can make chrome 147MB test works?
>
>
>
> Or we need to tune our network infrastructure?
>
> For now, I haven't been able to google anything yet.
>
>
>
> Thanks and regards,
> Eric
>
>
>
>
>
>
>
>
>
> On Thu, Oct 29, 2020 at 11:10 AM eric tse <hfe...@gmail.com> wrote:
>
> Good morning,
>
>
>
> Thanks for your excellent tip last night.
>
> We have some significant turn around from an investigation perspective.
>
>
>
> We’ve done some additional testing this morning and had a surprising
> result. Does this provide any hints to the cause?
>
>
>
> Firefox 60 MB:                   bad gateway
>
> Firefox 147 MB:                bad gateway
>
>
>
> Chrome 60 MB:                 success!
>
> Chrome 147 MB:              bad gateway
>
>
>
> IE 11 60 MB:                       bad gateway
>
> IE 11 147 MB:                    bad gateway
>
>
>
>  My client said that we’re bound to using IE 11 for this project, although
> Chrome was identified as a acceptable alternative.
>
> For now we can ignore his comment for troubleshooting.
>
>
>
> Is it a bug, or limitation, or work as designed?
>
> Or something we can tune (like browser or network infrastructure?) ?
>
> Is it caused by timing?
>
>
>
> Please advise.
>
> Eric
>
>
>
>
>
>
>
>
>
> On Thu, Oct 29, 2020 at 4:00 AM @lbutlr <krem...@kreme.com> wrote:
>
> On 28 Oct 2020, at 18:05, eric tse <hfe...@gmail.com> wrote:
> > We’re are getting a Bad Gateway error returned when trying to upload
> large files through an IE browser to our webserver.
>
> Have you tried with a currently supported browser?
>
> IE is on death watch.
>
> --
> If I were you boys, I wouldn't talk or even think about women.
>         'T'ain't good for your health.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
> -- The Wellcome Sanger Institute is operated by Genome Research Limited, a
> charity registered in England with number 1021457 and a company registered
> in England with number 2742969, whose registered office is 215 Euston Road,
> London, NW1 2BE.
>
> -- The Wellcome Sanger Institute is operated by Genome Research Limited, a
> charity registered in England with number 1021457 and a company registered
> in England with number 2742969, whose registered office is 215 Euston Road,
> London, NW1 2BE.
>

Reply via email to