Common errors

• First, determine whether the object is directly uploaded to OSS or uploaded to OSS through other proxies such as CDN. If the object is uploaded to OSS through CDN, the ETag of the object must be exposed and the following items must be configured for OSS: HTTP header, Access-Control-Allow-Origin, Access-Control-Allow-Mehtods, and Access-Control-Allow-Headers. For more information, see PutBucketCORS.
• If the upload failed because of timeout, we recommend that you use resumable upload to upload the object. By using resumable upload, you can upload object parts concurrently and customize the part size. When the OSS SDK returns an exception, view and analyze the exception information in detail.
• Delete the parts generated by the failed upload task and upload the object again.

• The requestID in the exception returned by the OSS SDK.
• The packets captured by running the following tcpdump command when you upload the object again.

  tcpdump -i <Outbound port name> -s0 host <OSS endpoint> -w faild.pcap

• Use tcpdump to capture packets on the client. Analyze the packets to determine whether the calculated signature is different from that on the OSS server because of incorrect header information in the request.

  POST /ttsservice%2Fpasswd? uploadId=D468E486D1D94D90A1AB8885A4E32AE0 HTTP/1.1
  Host: rokid.oss-cn-hangzhou.aliyuncs.com
  Accept-Encoding: identity
  Accept: */*
  Content-Length: 137
  date: Sat, 29 Dec 2018 07:32:34 GMT
  authorization: OSS LTAIknFr:r2KPR0y4E0G5tnU/MYdcvXHPQQ4=
  Content-Type: application/x-www-form-urlencoded
  User-Agent: aliyun-sdk-python/2.6.0(Linux/4.4.0-31-generic/x86_64;3.4.3)
  
  <CompleteMultipartUpload><Part><PartNumber>1</PartNumber><ETag>"3195544E19D99658706D51EF5"</ETag></Part></CompleteMultipartUpload>HTTP/1.1 403 Forbidden
  
  Server: AliyunOSS
  Date: Sat, 29 Dec 2018 07:33:43 GMT
  Content-Type: application/xml
  Content-Length: 1122
  Connection: keep-alive
  x-oss-request-id: 5C2723573183A12D
  x-oss-server-time: 0
  
  <? xml version="1.0" encoding="UTF-8"? >
  <Error>
   <Code>SignatureDoesNotMatch</Code>
   <Message>The request signature we calculated does not match the signature you provided. Check your key and signing method. </Message>
   <RequestId> 5C2723573183A12D </RequestId>
   <HostId>rokid.oss-cn-hangzhou.aliyuncs.com</HostId>
   <OSSAccessKeyId> LTAXXX </OSSAccessKeyId>
   <SignatureProvided>r2KPR0y4E0G5tnU/MYdcvXHPQQ4=</SignatureProvided>
   <StringToSign>POST
  application/x-www-form-urlencoded
  Sat, 29 Dec 2018 07:32:34 GMT
  /rokid/ttsservice/passwd? uploadId=D468E486D1D94D90A1AB8885A4E32AE0</StringToSign>
   <StringToSignBytes>50 4F 53 54 0A 0A 61 70 70 6C 69 63 61 74 69 6F 6E 2F 78 2D 77 77 77 2D 66 6F 72 6D 2D 75 72 6C 65 6E 63 6F 64 65 64 0A 53 61 74 2C 20 32 39 20 44 65 63 20 32 30 31 38 20 30 37 3A 33 32 3A 33 34 20 47 4D 54 0A 2F 72 6F 6B 69 64 2D 6F 70 73 2D 6D 6F 64 65 6C 2F 74 74 73 73 65 72 76 69 63 65 2F 70 61 73 73 77 64 3F 75 70 6C 6F 61 64 49 64 3D 44 34 36 38 45 34 38 36 44 31 44 39 34 44 39 30 41 31 41 42 38 38 38 35 41 34 45 33 32 41 45 30 </StringToSignBytes>
  </Error>

  The preceding code is the packets captured by tcpdump on the client. Use the captured header information in the following script to caculate the signature, and check whether the calculated signature is consistent with the signature in the captured packets.

  import base64
  import hmac
  import sha
  mac = hmac.new("<Secretkey>","POST\n\napplication/x-www-form-urlencoded\nSat, 29 Dec 2018 07:32:34 GMT\n/rokid/ttsservice/passwd? uploadId=D468E486D1D94D90A1AB8885A4E32AE0", sha)
  Signature = base64.b64encode(mac.digest())
  print(Signature)

  • If the signatures are consistent, the signature in the request generated by the SDK is correct. If the calculated signature is inconsistent with the signature in the captured packets, it may because that the MD5 hash calculated based on the signature is different in Ubuntu systems due to compatibility issues.
  • If the signature received by the server and that calculated on the client are inconsistent, the content in the request has been modified. We recommend that you upload the object through HTTPS.

objc[2483]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called.
objc[2483]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.