FileLinked ei lataudu Firestickiin? Amazon estää tiedostojen linkityksen?

Mielestämme saamme paljon epäonnistuneita latausyrityksiä ja haluamme ymmärtää miksi.

Tarjoamme latauksia sähköpostilinkin kautta (tyypillinen):

 http://www.semanticdesigns.com/deliverEval/ 

Tomcat käsittelee tämän Linuxissa jsp-tiedoston kautta seuraavalla koodilla:

response.addHeader( 'Content-Disposition', 'attachment; filename=' + fileTail ); response.addHeader( 'Content-Type', 'application/x-msdos-program' ); byte[] buf = new byte[8192]; int read; try { java.io.FileInputStream input = new java.io.FileInputStream( filename ); java.io.OutputStream o = response.getOutputStream(); while( ( read = input.read( buf, 0, 8192 ) ) != -1 ){ o.write( buf, 0, read ); } o.flush(); } catch( Exception e ){ util.fatalError( request.getRequestURI(), 'Error sending file '' + filename + '' to client', e ); throw e; } 

Saamme paljon ilmoitettuja virheitä (noin 50% virhesuhde):

 URI --- /deliverEval/download.jsp Code Message: Error sending file '/home/sd/ShippingMasters/DMS/Domains/C/GCC3/Tools/TestCoverage/SD_C~GCC3_TestCoverage.1.6.12.exe' to client Stack Trace ----------- null at org.apache.coyote.tomcat5.OutputBuffer.realWriteBytes(byte[], int, int) (Unknown Source) at org.apache.tomcat.util.buf.ByteChunk.append(byte[], int, int) (Unknown Source) at org.apache.coyote.tomcat5.OutputBuffer.writeBytes(byte[], int, int) (Unknown Source) at org.apache.coyote.tomcat5.OutputBuffer.write(byte[], int, int) (Unknown Source) at org.apache.coyote.tomcat5.CoyoteOutputStream.write(byte[], int, int) (Unknown Source) at org.apache.jsp.deliverEval.download_jsp._jspService(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) (Unknown Source) at org.apache.jasper.runtime.HttpJspBase.service(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) (Unknown Source) at javax.servlet.http.HttpServlet.service(javax.servlet.ServletRequest, javax.servlet.ServletResponse) (Unknown Source) at org.apache.jasper.servlet.JspServletWrapper.service(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse, boolean) (Unknown Source) at org.apache.jasper.servlet.JspServlet.serviceJspFile(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse, java.lang.String, java.lang.Throwable, boolean) (Unknown Source) at org.apache.jasper.servlet.JspServlet.service(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) (Unknown Source) at javax.servlet.http.HttpServlet.service(javax.servlet.ServletRequest, javax.servlet.ServletResponse) (Unknown Source) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(javax.servlet.ServletRequest, javax.servlet.ServletResponse) (Unknown Source) at org.apache.catalina.core.ApplicationFilterChain.doFilter(javax.servlet.ServletRequest, javax.servlet.ServletResponse) (Unknown Source) at org.apache.catalina.core.StandardWrapperValve.invoke(org.apache.catalina.Request, org.apache.catalina.Response, org.apache.catalina.ValveContext) (Unknown Source) 

Emme ymmärrä, miksi tämän prosentin pitäisi olla niin korkea. Onko mitään keinoa saada lisätietoja virheen syystä?

On hyödyllistä tietää, että nämä ovat melko isoja asiakirjoja, 3-50 megatavua. He asuvat Linux-palvelimella, joten niiden lukeminen on vain paikallisen levyn lukemista, eikä se todennäköisesti edistä ongelmaa. Mutta pelkkä koko voi olla ongelma vastaanottajien selaimelle?

Onko tällainen virhetaso tyypillistä latauksille? Henkilökohtainen kokemukseni muiden asiakirjojen lataamisesta ei ehdota sisäiset yrityksemme osoittavat tämän olevan erittäin luotettavaa, mutta toimimme sisäisessä verkostossamme tällaisia ​​kokeita varten, joten puuttuu väliintulevan Internetin monimutkaisuus.

  • ClientAbortException ..? (helppo testata, yritä ladata 50 Mt: n tiedosto ja lopeta lataus puolivälissä)
  • @danlefree: Uskon, että jos asiakas keskeyttää, meidän pitäisi nähdä jotain tällaista, eikö. Onko niin, että 50% käyttäjistä keskeyttää latauksensa? Voisiko olla niin, että keskeytät latauksen, jos he havaitsevat sen olevan iso tai kestää kauemmin kuin useimmat pienet lataukset vievät? Etsin teknisiä syitä (kuten ehdotit) ja psykologisia selityksiä (käyttäjillä on suuri hylkäysaste) ihmisiltä, ​​joilla on kokemusta tästä.
+100

Onko mitään keinoa saada lisätietoja virheen syystä?

Lisää seuraava lokiisi: (En ole Java-guru, mutta uskon, että suurin osa tarvitsemistasi muuttujista on kuvattu org.apache.catalina.connector.Request-ohjeissa)

Täysi poikkeus kaatopaikka - e.toString() - toimitettu koodinäyte ei tee eroa asiakkaan keskeytyksen ja tiedoston avaamisen epäonnistumisen välillä, joten tarvitaan lisätietoja, jos asiat menevät pieleen, ellei kirjaamista tapahdu muualla, kun poikkeus heitetään.

Asiakkaan IP, käyttäjäagentti ja HTTP-viittaus - Onko monilla pyynnöillä yhteinen ketju? (esim. botti, lähdeverkko, maantieteellinen sijainti tai etäisyys, selain, linkitetty toisesta sivustosta, jossa lataustiedoston kokoa ei näytetä jne.)

  • 1 Minulla ei ole ollut mahdollisuutta seurata tätä, mutta olet ainoa henkilö, joka antoi minkäänlaisen vihjeen. Annan sinulle pisteet ... ja kiitos.

työskennellyt sinulle: Charles Robertson | Haluatko yhteyttä?