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. >
