2014-04-01 12 views
7

Jestem PUTting plików do S3 przez żądania ajax i około 50% czasu dostaję błędy ERR_CONNECTION_RESET.ERR_CONNECTION_RESET, gdy PUTting do S3

Wiem, że wnioski są poprawnie podpisane - wszelkie pomysły, które mogą być przyczyną tego problemu? Ponownie, jest to sporadyczny problem, który widzę z wielu lokalizacji i maszyn.

Oto odpowiedni kod coffeescript, którego używam, aby umieścić moje pliki w S3. Pochodzi z pracy Micah Roberson i Rok Krulec pod numerem http://micahroberson.com/upload-files-directly-to-s3-w-backbone-on-heroku/ i http://codeartists.com/post/36892733572/how-to-directly-upload-files-to-amazon-s3-from-your.

createCORSRequest: (method, url) -> 
    xhr = new XMLHttpRequest() 

    if xhr.withCredentials? 
     xhr.open method, url, true 
    else if typeof XDomainRequest != "undefined" 
     xhr = new XDomainRequest() 
     xhr.open method, url 
    else 
     xhr = null 

    xhr 

    uploadToS3: (file, signature) -> 
    this_s3upload = this 
    this_s3upload.signature = signature 
    url = signature.signed_request 

    xhr = @createCORSRequest 'PUT', decodeURIComponent(signature.signed_request) 

    if !xhr 
     @onError 'CORS not supported' 
    else 
     xhr.onload =() -> 
     if xhr.status == 200 
      this_s3upload.onProgress 100, 'Upload completed.' 
      this_s3upload.onFinishS3Put file, this_s3upload.signature 
     else 
      this_s3upload.onError file, 'Upload error: ' + xhr.status 

     xhr.onerror =() -> 
     this_s3upload.onError file, 'XHR error.', this_s3upload.signature 

     xhr.upload.onprogress = (e) -> 
     if e.lengthComputable 
      percentLoaded = Math.round (e.loaded/e.total) * 100 

      if percentLoaded == 100 
      message = "Finalizing" 
      else 
      message = "Uploading" 

      this_s3upload.onProgress xhr, file, percentLoaded, message, this_s3upload.signature 

     xhr.onabort = -> 
     this_s3upload.onAbort file, "XHR cancelled by user.", this_s3upload.signature 

    xhr.setRequestHeader 'Content-Type', file.type 
    xhr.setRequestHeader 'x-amz-acl', 'public-read' 
    xhr.send file 

Aktualizacja

byłem już bardzo profesjonalną obsługę z Amazon w tej sprawie. Zgodnie z ich sugestią utworzyłem instancję EC2 Windows, załadowałem na nią przeglądarkę Chrome i próbowałem przesłać 5 plików 10 razy z moim kodem. Nie widziałem błędu raz. Od czasu do czasu pojawiały się błędy SignatureDoesNotMatch, ale nie występował jeden błąd ERR_CONNECTION_RESET. Nadal widzę błędy ERR_CONNECTION_RESET na każdym innym kliencie/lokalizacji, z której korzystam.

Aktualizacja Nadal nie ma rozwiązania tutaj. Przeniosłem się z użycia samoczynnego algorytmu podpisywania do algorytmu dostarczonego przez boto. Brak wpływu na problem ERR_CONNECTION_RESET.

+0

Jeśli ktoś inny ma ten sam problem, byłbym wdzięczny wiedząc, że nie jestem sam. ;) – Erik

+1

Mam ten sam problem! Używam tego samego zestawu zasobów (bloga i kodu modelu) i mam dokładnie taki sam wynik. Mniej więcej w połowie przypadków żądanie daje ERR_CONNECTION_RESET bez żadnych innych informacji. –

+1

Dzięki Joan. Mam aktywne pytanie z AWS, ale wymaga to ode mnie powtórzenia kodu przeglądarki jako autonomicznego procesu do ich debugowania - co wymaga pewnego rozwoju. – Erik

Odpowiedz

1

W końcu zrezygnowałem z tego, żeby to zadziałało. Zamiast tego używam teraz Fine Uploader, aby zapewnić tę funkcjonalność.

0

Przypuszczam, że ten problem nie ma żadnej decyzji.

Spróbuj żądania POST: https://aws.amazon.com/articles/1434

<form action="https://s3-bucket.s3.amazonaws.com/" method="post" enctype="multipart/form-data"> 
    <input type="hidden" name="key" value="uploads/${filename}"> 
    <input type="hidden" name="AWSAccessKeyId" value="YOUR_AWS_ACCESS_KEY"> 
    <input type="hidden" name="acl" value="private"> 
    <input type="hidden" name="success_action_redirect" value="http://localhost/"> 
    <input type="hidden" name="policy" value="YOUR_POLICY_DOCUMENT_BASE64_ENCODED"> 
    <input type="hidden" name="signature" value="YOUR_CALCULATED_SIGNATURE"> 
    <input type="hidden" name="Content-Type" value="image/jpeg"> 
    <!-- Include any additional input fields here --> 

    File to upload to S3: 
    <input name="file" type="file"> 
    <br> 
    <input type="submit" value="Upload File to S3"> 
</form> 

Zastosowanie FormData dołączyć pola, jeśli wolisz AJAX wysyłania

Aby podpisać wniosek w nodejs: Amazon S3 POST api, and signing a policy with NodeJS

1

wpadłem na ten problem, gdy przesyłanie większych plików (długie żądania) ze wstępnie podpisanymi adresami URL, po Heroku's example (węzeł aws sdk):

app.get('/sign-s3', (req, res) => { 
    const s3 = new aws.S3(); 
    const fileName = req.query['file-name']; 
    const fileType = req.query['file-type']; 
    const s3Params = { 
    Bucket: S3_BUCKET, 
    Key: fileName, 
    Expires: 60, 
    ContentType: fileType, 
    ACL: 'public-read' 
    }; 

    s3.getSignedUrl('putObject', s3Params, (err, data) => { 
    if(err){ 
     console.log(err); 
     return res.end(); 
    } 
    const returnData = { 
     signedRequest: data, 
     url: `https://${S3_BUCKET}.s3.amazonaws.com/${fileName}` 
    }; 
    res.write(JSON.stringify(returnData)); 
    res.end(); 
    }); 
}); 

Parametr "Wygasa" powoduje, że podpisany URL jest ważny przez 60 sekund.

Doszedłem do wniosku, że żądanie kończy się wraz z wygaśnięciem podpisanego adresu URL w trakcie przesyłania (mimo że było ważne, gdy rozpoczęto wysyłanie).

Nie ulega awarii dokładnie po 60 sekundach, ale losowo pomiędzy 60 a 120 sekundami. Przez większość czasu klient loguje ERR_CONNECTION_RESET, a innym razem loguje się 403 ZABRONIONE.

Po wykonaniu rozruchu do 3600 nie miałem już żadnych problemów.

Podejrzewam, że problem nie wystąpił w EC2, ponieważ mają one bardzo dużą szybkość wysyłania.