Object Storage Service:callback

Limitations

• Disponibilité par région

  La fonctionnalité de callback est prise en charge dans les régions suivantes : Chine (Hangzhou), Chine (Shanghai), Chine (Qingdao), Chine (Beijing), Chine (Zhangjiakou), Chine (Hohhot), Chine (Ulanqab), Chine (Shenzhen), Chine (Heyuan), Chine (Guangzhou), Chine (Chengdu), Chine (Hong Kong), États-Unis (Silicon Valley), États-Unis (Virginie), Japon (Tokyo), Singapour, Malaisie (Kuala Lumpur), Indonésie (Jakarta), Philippines (Manille), Allemagne (Francfort), Royaume-Uni (Londres) et Émirats arabes unis (Dubaï).

• Comportement du callback

  • Une requête de callback doit recevoir une réponse dans un délai de 5 secondes. Sinon, le callback échoue.

  • Un échec du callback n'affecte pas la réussite du téléchargement de l'objet.

  • OSS ne réessaie pas automatiquement les callbacks ayant échoué.

• Opérations prises en charge

  Vous pouvez configurer des callbacks pour les opérations PutObject, PostObject et CompleteMultipartUpload. Le gestionnaire de téléchargement de fichiers et les URL signées des SDK V2, qui s'appuient sur ces opérations de base, prennent également en charge les callbacks.

Implémentation côté client

Pour une implémentation plus rapide, reportez-vous aux exemples de code fournis dans les SDKs .

Pour déclencher un callback OSS automatique après le téléchargement d'un objet, incluez le paramètre callback et le paramètre optionnel callback-var dans votre requête de téléchargement.

1. Construisez le paramètre callback.

   Ce paramètre définit l'URL du serveur d'application et le format du corps de la requête. Il doit être structuré comme un objet JSON, puis encodé en Base64.

   1. Exemple de configuration minimale :

      {
      "callbackUrl":"http://oss-demo.aliyuncs.com:23450",
      "callbackBody":"bucket=${bucket}&object=${object}&my_var=${x:my_var}"
      }

      Dans cet exemple :

      • callbackUrl : L'adresse du serveur d'application. Vous devez définir ce paramètre sur l'adresse réelle. Cette rubrique utilise http://oss-demo.aliyuncs.com:23450 à titre d'exemple.

      • callbackBody : Le contenu du corps de la requête de callback. Vous pouvez utiliser des espaces réservés pour inclure dynamiquement des informations de téléchargement, telles que ${bucket} pour le nom du bucket, ${object} pour le chemin complet du fichier, et ${x:xxx} pour référencer des variables personnalisées. OSS remplace ces espaces réservés par des valeurs réelles lors du callback. Pour plus d'informations sur les paramètres système pris en charge, consultez la section Paramètres système pris en charge par callbackBody.

   2. Exemple de configuration avancée :

      {
      "callbackUrl":"http://oss-demo.aliyuncs.com:23450",
      "callbackHost":"oss-cn-hangzhou.aliyuncs.com",
      "callbackBody":"bucket=${bucket}&object=${object}&my_var=${x:my_var}",
      "callbackBodyType":"application/x-www-form-urlencoded",
      "callbackSNI":false
      }

      Pour plus d'informations sur les champs, consultez la section Paramètre de callback.

2. Construisez le paramètre callback-var (facultatif)

   Important

   Le paramètre callback-var doit être au format JSON. La clé de chaque paramètre personnalisé doit commencer par x: et contenir uniquement des lettres minuscules, par exemple x:uid.

   Utilisez ce paramètre pour transmettre des informations métier personnalisées, telles qu'un ID utilisateur ou un numéro de commande, à votre serveur d'application. Exemple :

   {
     "x:uid": "12345",
     "x:order_id": "67890"
   }

   Le paramètre callback-var doit être utilisé conjointement avec le paramètre callbackBody. Pour les variables personnalisées de l'exemple précédent (uid et order_id), référencez-les dans callbackBody en utilisant l'espace réservé ${x:xxx}. Exemple :

   {
     "callbackUrl": "http://oss-demo.aliyuncs.com:23450",
     "callbackBody": "uid=${x:uid}&order=${x:order_id}"
   }

   Lorsque le callback est déclenché, OSS envoie le contenu suivant, en supposant que callbackBodyType est défini sur application/x-www-form-urlencoded :

   uid=12345&order=67890

3. Encodez en Base64 les paramètres callback et callback-var.

   • Exemple : encodage du paramètre callback****

     Paramètre callback original :

     {
         "callbackUrl": "http://oss-demo.aliyuncs.com:23450",
         "callbackHost": "your.callback.com",
         "callbackBody": "bucket=${bucket}&object=${object}&uid=${x:uid}&order=${x:order_id}",
         "callbackBodyType": "application/x-www-form-urlencoded",
         "callbackSNI": false
     }

     Résultat après encodage Base64 :

     eyJjYWxsYmFja0hvc3QiOiAieW91ci5jYWxsYmFjay5jb20iLCAiY2FsbGJhY2tVcmwiOiAiaHR0cDovL29zcy1kZW1vLmFsaXl1bmNzLmNvbToyMzQ1MCIsICJjYWxsYmFja0JvZHkiOiAiYnVja2V0PSR7YnVja2V0fSZvYmplY3Q9JHtvYmplY3R9JnVpZD0ke3g6dWlkfSZvcmRlcj0ke3g6b3JkZXJfaWR9IiwgImNhbGxiYWNrQm9keVR5cGUiOiAiYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIiwgImNhbGxiYWNrU05JIjogZmFsc2V9

   • Exemple : encodage du paramètre callback-var****

     Paramètre callback-var original :

     {
       "x:uid": "12345",
       "x:order_id": "67890"
     }

     Résultat après encodage Base64 :

     eyJ4OnVpZCI6ICIxMjM0NSIsICJ4Om9yZGVyX2lkIjogIjY3ODkwIn0=

4. Ajoutez les paramètres encodés à la requête.

   Après avoir encodé les paramètres, vous pouvez les transmettre à OSS de l'une des manières suivantes.

   Header (Recommended)

   Cette méthode convient aux téléchargements depuis un SDK ou du code backend. Elle offre une sécurité élevée et est recommandée. Vous pouvez transmettre les paramètres de callback en définissant les champs d'en-tête HTTP x-oss-callback et x-oss-callback-var.

   • x-oss-callback : Le paramètre callback encodé en Base64.

   • x-oss-callback-var (facultatif) : Le paramètre callback-var encodé en Base64.

   Remarque : Lorsque vous calculez la signature de la requête, ces deux paramètres doivent être inclus dans les en-têtes canoniques pour garantir la validité de la requête.

   Exemple : transmission des paramètres de callback dans l'en-tête

   PUT /your_object HTTP/1.1
   Host: callback-test.oss-test.aliyun-inc.com
   Accept-Encoding: identity
   Content-Length: 5
   x-oss-callback-var: eyJ4OnVpZCI6ICIxMjM0NSIsICJ4Om9yZGVyX2lkIjogIjY3ODkwIn0=
   User-Agent: aliyun-sdk-python/0.4.0 (Linux/2.6.32-220.23.2.ali1089.el5.x86_64/x86_64;2.5.4)
   x-oss-callback: eyJjYWxsYmFja0hvc3QiOiAieW91ci5jYWxsYmFjay5jb20iLCAiY2FsbGJhY2tVcmwiOiAiaHR0cDovL29zcy1kZW1vLmFsaXl1bmNzLmNvbToyMzQ1MCIsICJjYWxsYmFja0JvZHkiOiAiYnVja2V0PSR7YnVja2V0fSZvYmplY3Q9JHtvYmplY3R9JnVpZD0ke3g6dWlkfSZvcmRlcj0ke3g6b3JkZXJfaWR9IiwgImNhbGxiYWNrQm9keVR5cGUiOiAiYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIiwgImNhbGxiYWNrU05JIjogZmFsc2V9
   Host: callback-test.oss-test.aliyun-inc.com
   Expect: 100-Continue
   Date: Wed, 26 Apr 2023 03:46:17 GMT
   Content-Type: text/plain
   Authorization: OSS qn6q**************:77Dv****************
   Test

   POST request body

   Cette méthode s'applique uniquement aux téléchargements PostObject. Les paramètres de callback doivent être transmis en tant que champs de formulaire dans le corps de la requête POST.

   • Paramètre callback : transmettez ce paramètre en tant que champ de formulaire distinct. La valeur est la configuration JSON encodée en Base64.

     --9431149156168
     Content-Disposition: form-data; name="callback"
     eyJjYWxsYmFja0hvc3QiOiAieW91ci5jYWxsYmFjay5jb20iLCAiY2FsbGJhY2tVcmwiOiAiaHR0cDovL29zcy1kZW1vLmFsaXl1bmNzLmNvbToyMzQ1MCIsICJjYWxsYmFja0JvZHkiOiAiYnVja2V0PSR7YnVja2V0fSZvYmplY3Q9JHtvYmplY3R9JnVpZD0ke3g6dWlkfSZvcmRlcj0ke3g6b3JkZXJfaWR9IiwgImNhbGxiYWNrQm9keVR5cGUiOiAiYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIiwgImNhbGxiYWNrU05JIjogZmFsc2V9

   • Paramètre callback-var (variables personnalisées) : chaque variable personnalisée doit être transmise en tant que champ de formulaire distinct. Vous ne pouvez pas les encapsuler dans un seul champ callback-var.

     Par exemple, considérez les variables personnalisées uid et order_id :

     {
       "x:uid": "12345",
       "x:order_id": "67890"
     }

     Vous devez les convertir en deux champs de formulaire distincts.

     --9431149156168
     Content-Disposition: form-data; name="x:uid"
     12345
     --9431149156168
     Content-Disposition: form-data; name="x:order_id"
     67890

   • Vérifiez le paramètre callback (facultatif) : vous pouvez spécifier des conditions de validation pour le paramètre callback dans la policy. Si cette condition est omise, le paramètre n'est pas validé lors du téléchargement. Exemple :

     { "expiration": "2021-12-01T12:00:00.000Z",
       "conditions": [
         {"bucket": "examplebucket" },
         {"callback": "eyJjYWxsYmFja0hvc3QiOiAieW91ci5jYWxsYmFjay5jb20iLCAiY2FsbGJhY2tVcmwiOiAiaHR0cDovL29zcy1kZW1vLmFsaXl1bmNzLmNvbToyMzQ1MCIsICJjYWxsYmFja0JvZHkiOiAiYnVja2V0PSR7YnVja2V0fSZvYmplY3Q9JHtvYmplY3R9JnVpZD0ke3g6dWlkfSZvcmRlcj0ke3g6b3JkZXJfaWR9IiwgImNhbGxiYWNrQm9keVR5cGUiOiAiYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIiwgImNhbGxiYWNrU05JIjogZmFsc2V9"},
         ["starts-with", "$key", "user/eric/"]
       ]
     }

   URL

   • Cette méthode est généralement utilisée pour télécharger des objets avec une URL signée. Les paramètres de callback encodés en Base64 sont ajoutés à l'URL pour activer le callback automatique. Cependant, cette méthode expose les informations de callback dans l'URL et présente des risques de sécurité. Utilisez-la uniquement pour un accès temporaire ou dans des scénarios peu sensibles.

   • Si vous choisissez de transmettre les paramètres de callback dans l'URL, vous devez inclure le paramètre callback. Le paramètre callback-var est facultatif. Lors du calcul de la signature, ces paramètres doivent être inclus dans la Canonical Query String. Pour plus d'informations, consultez la section Signature Version 4.

     Exemple :

     PUT /your_object?OSSAccessKeyId=LTAI******************&Signature=vjby*************************************&Expires=1682484377&callback-var=eyJ4OnVpZCI6ICIxMjM0NSIsICJ4Om9yZGVyX2lkIjogIjY3ODkwIn0=&callback=eyJjYWxsYmFja0hvc3QiOiAieW91ci5jYWxsYmFjay5jb20iLCAiY2FsbGJhY2tVcmwiOiAiaHR0cDovL29zcy1kZW1vLmFsaXl1bmNzLmNvbToyMzQ1MCIsICJjYWxsYmFja0JvZHkiOiAiYnVja2V0PSR7YnVja2V0fSZvYmplY3Q9JHtvYmplY3R9JnVpZD0ke3g6dWlkfSZvcmRlcj0ke3g6b3JkZXJfaWR9IiwgImNhbGxiYWNrQm9keVR5cGUiOiAiYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIiwgImNhbGxiYWNrU05JIjogZmFsc2V9 HTTP/1.1
     Host: callback-test.oss-cn-hangzhou.aliyuncs.com
     Date: Wed, 26 Apr 2023 03:46:17 GMT
     Content-Length: 5
     Content-Type: text/plain

Implémentation côté serveur

La section suivante décrit le flux de traitement côté serveur. Pour des exemples de code dans différents langages de programmation, consultez la section Exemples de code côté serveur .

Votre serveur d'application doit être capable d'effectuer les actions suivantes :

1. Recevoir les requêtes POST d'OSS

   Après un téléchargement d'objet réussi, OSS envoie automatiquement une requête POST à votre serveur d'application. Le code suivant montre un exemple de requête :

   POST /test HTTP/1.1
   Host: your.callback.com
   Connection: close
   Authorization: GevnM3**********3j7AKluzWnubHSVWI4dY3VsIfUHYWnyw==
   Content-MD5: iKU/O/JB***ZMd8Ftg==
   Content-Type: application/x-www-form-urlencoded
   Date: Tue, 07 May 2024 03:06:13 GMT
   User-Agent: aliyun-oss-callback
   x-oss-bucket: your_bucket
   x-oss-pub-key-url: aHR0cHM6Ly9nb3NzcHVi**********vY2FsbGJeV92MS5wZW0=
   x-oss-request-id: 66399AA50*****3334673EC2
   x-oss-requester: 23313******948342006
   x-oss-signature-version: 1.0
   x-oss-tag: CALLBACK
   bucket=your_bucket&object=your_object&uid=12345&order_id=67890

2. Vérifiez la signature de la requête pour des raisons de sécurité (facultatif)

   Pour vous assurer que les requêtes de callback proviennent bien d'OSS, vérifiez la signature de la requête sur votre serveur d'application. Pour des instructions détaillées, consultez la section Configurations recommandées.

   Remarque

   La vérification de la signature est facultative et peut être activée en fonction de vos exigences de sécurité.

3. Envoyez une réponse de callback

   Après avoir reçu une requête de callback, votre serveur d'application doit envoyer une réponse à OSS. La réponse doit répondre aux exigences suivantes :

   • Le serveur d'application doit renvoyer HTTP/1.1 200 OK pour indiquer un succès.

   • L'en-tête de réponse doit inclure Content-Length.

   • Le corps de la réponse prend en charge les formats JSON ou XML. Cette rubrique utilise JSON à titre d'exemple. Si vous souhaitez utiliser le format XML, ajoutez Content-Type: application/xml à l'en-tête de réponse.

   Par exemple, le serveur d'application renvoie {"Status": "OK"}.

   Remarque : la version Python de cet exemple est la 2.7.6. Nous vous recommandons d'utiliser Python 3 pour le développement.

   HTTP/1.0 200 OK
   Server: BaseHTTP/0.3 Python/2.7.6
   Date: Mon, 14 Sep 2015 12:37:27 GMT
   Content-Type: application/json
   Content-Length: 9
   {"Status": "OK"}

   OSS transfère ensuite cette réponse au client. Exemple :

   HTTP/1.1 200 OK
   Date: Mon, 14 Sep 2015 12:37:27 GMT
   Content-Type: application/json
   Content-Length: 9
   Connection: keep-alive
   ETag: "D8E8FCA2DC0F896FD7CB4CB0031BA249"
   Server: AliyunOSS
   x-oss-bucket-version: 1442231779
   x-oss-request-id: 55F6BF87207FB30F2640C548
   {"Status": "OK"}

   Important

   Pour une requête CompleteMultipartUpload, si le corps de la réponse originale contient du contenu (tel que des informations au format JSON), ce contenu est écrasé par la réponse du callback lorsque le callback de téléchargement est activé. Par exemple, dans ce cas, le contenu est écrasé par {"Status": "OK"}.

Vérification de la signature de la requête

Une fois les paramètres de rappel configurés, OSS envoie une requête POST de rappel au serveur d'application selon l'URL spécifiée dans le paramètre callbackUrl. Pour garantir que la requête provient bien d'OSS, vous pouvez vérifier la signature de la requête de rappel. Les étapes suivantes décrivent ce processus de vérification.

1. Génération de la signature par OSS

   OSS utilise l'algorithme de chiffrement asymétrique RSA avec un hachage MD5 pour générer une signature du contenu de la requête. Cette signature est ensuite incluse dans le champ authorization de l'en-tête de la requête.

   • La signature est calculée à l'aide de la formule suivante :

     authorization = base64_encode(rsa_sign(private_key, url_decode(path) + query_string + '\n' + body, md5))

     Remarque

     Dans cette formule, private_key représente la clé privée, path le chemin de la ressource de la requête de rappel, query_string la chaîne de requête et body le corps du message du rappel.

   • Étapes de génération de la signature :

     1. Construisez la chaîne à signer : décodez l'URL du chemin de la ressource, puis ajoutez la chaîne de requête d'origine, un caractère de nouvelle ligne (\n) et le corps du message de rappel.

     2. Générez la signature RSA : utilisez la clé privée pour signer la chaîne à signer. La fonction de hachage utilisée est MD5.

     3. Encodez le résultat en Base64 pour obtenir la signature finale, puis incluez-la dans l'en-tête authorization de la requête de rappel.

   • Exemple de génération de signature :

     POST /index.php?id=1&index=2 HTTP/1.0
     Host: 172.16.XX.XX
     Connection: close
     Content-Length: 18
     authorization: kKQeGTRccDKyHB3H9vF+xYMSrmhMZj****/kdD1ktNVgbWEfYTQG0G2SU/RaHBovRCE8OkQDjC3uG33esH2t****
     Content-Type: application/x-www-form-urlencoded
     User-Agent: http-client/0.0.1
     x-oss-pub-key-url: aHR0cDovL2dvc3NwdWJsaWMuYWxpY2RuLmNvbS9jYWxsYmFja19wdWJfa2V5X3YxLnsr****
     bucket=examplebucket

     Le chemin est /index.php, la chaîne de requête est ?id=1&index=2, le corps est bucket=examplebucket et la signature résultante est kKQeGTRccDKyHB3H9vF+xYMSrmhMZjzzl2/kdD1ktNVgbWEfYTQG0G2SU/RaHBovRCE8OkQDjC3uG33esH2t****.

2. Vérification de la signature par le serveur de rappel

   Votre serveur d'application doit vérifier la signature de la requête provenant d'OSS afin d'en confirmer l'authenticité. Le processus de vérification est le suivant :

   1. Obtenez la clé publique :

      Récupérez l'URL de la clé publique encodée en Base64 depuis le champ x-oss-pub-key-url de l'en-tête de la requête, puis décodez-la.

      public_key = urlopen(base64_decode(value of the x-oss-pub-key-url header))

      Exemple de valeur avant décodage :

      aHR0cDovL2dvc3NwdWJsaWMuYWxpY2RuLmNvbS9jYWxsYmFja19wdWJfa2V5X3YxLnBlbQ==

      Après décodage :

      http://gosspublic.alicdn.com/callback_pub_key_v1.pem

      Remarque

      L'URL de la clé publique doit commencer par http://gosspublic.alicdn.com/ ou https://gosspublic.alicdn.com/. Étant donné que le contenu à cette URL ne change pas, nous vous recommandons de mettre en cache la clé publique pour éviter les interruptions de service dues aux fluctuations du réseau.

   2. Décodez la signature.

      Récupérez la signature depuis le champ authorization de l'en-tête de la requête, puis décodez-la en Base64.

      signature = base64_decode(value of the authorization header)

   3. Construisez la chaîne à vérifier.

      Concaténez le chemin de la ressource, la chaîne de requête, un caractère de nouvelle ligne (\n) et le corps du message de rappel selon le format suivant :

      sign_str = url_decode(path) + query_string + ‘\n’ + body

   4. Effectuez la vérification de la signature.

      Utilisez le hachage MD5 et la clé publique RSA pour effectuer la vérification.

      result = rsa_verify(public_key, md5(sign_str), signature)

3. Exemple de vérification de signature

   Le code Python 3 ci-dessous illustre la vérification d'une signature sur un serveur d'application. Cet exemple nécessite la bibliothèque M2Crypto.

   import http.client
   import base64
   import hashlib
   import urllib.request
   import urllib.parse
   import socket
   from http.server import BaseHTTPRequestHandler, HTTPServer
   from M2Crypto import RSA
   from M2Crypto import BIO
   def get_local_ip():
       try:
           csock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
           csock.connect(('8.8.8.8', 80))
           (addr, port) = csock.getsockname()
           csock.close()
           return addr
       except socket.error:
           return ""
   class MyHTTPRequestHandler(BaseHTTPRequestHandler):
       '''
       def log_message(self, format, *args):
           return
       '''
       def do_POST(self):
           # Get the public key.
           pub_key_url = ''
           try:
               pub_key_url_base64 = self.headers['x-oss-pub-key-url']
               pub_key_url = base64.b64decode(pub_key_url_base64).decode()
               if not pub_key_url.startswith("http://gosspublic.alicdn.com/") and not pub_key_url.startswith("https://gosspublic.alicdn.com/"):
                   self.send_response(400)
                   self.end_headers()
                   return
               url_reader = urllib.request.urlopen(pub_key_url)
               # You can cache the public key. We recommend caching the public key content based on the public key URL to improve performance.
               pub_key = url_reader.read() 
           except Exception as e:
               print('pub_key_url : ' + pub_key_url)
               print('Get pub key failed! Error:', str(e))
               self.send_response(400)
               self.end_headers()
               return
           # Get the signature.
           authorization_base64 = self.headers['authorization']
           authorization = base64.b64decode(authorization_base64)
           # Get the callback body.
           content_length = self.headers['content-length']
           callback_body = self.rfile.read(int(content_length))
           # Construct the string for signature verification.
           auth_str = ''
           pos = self.path.find('?')
           if -1 == pos:
               auth_str = urllib.parse.unquote(self.path) + '\n' + callback_body.decode()
           else:
               auth_str = urllib.parse.unquote(self.path[0:pos]) + self.path[pos:] + '\n' + callback_body.decode()
           print(auth_str)
           # Verify the signature.
           auth_md5 = hashlib.md5(auth_str.encode()).digest()
           bio = BIO.MemoryBuffer(pub_key)
           rsa_pub = RSA.load_pub_key_bio(bio)
           try:
               result = rsa_pub.verify(auth_md5, authorization, 'md5')
           except:
               result = False
           if not result:
               print('Authorization verify failed!')
               print('Public key : %s' % (pub_key))
               print('Auth string : %s' % (auth_str))
               self.send_response(400)
               self.end_headers()
               return
           # Perform subsequent operations based on the callback_body.
           # Send a response to OSS.
           resp_body = '{"Status":"OK"}'
           self.send_response(200)
           self.send_header('Content-Type', 'application/json')
           self.send_header('Content-Length', str(len(resp_body)))
           self.end_headers()
           self.wfile.write(resp_body.encode())
   class MyHTTPServer(HTTPServer):
       def __init__(self, host, port):
           super().__init__((host, port), MyHTTPRequestHandler)
   if __name__ == '__main__':
       server_ip = get_local_ip()
       server_port = 23451
       server = MyHTTPServer(server_ip, server_port)
       server.serve_forever()

   Le tableau suivant fournit des exemples de code côté serveur pour d'autres langages.

   Langage	Description
   Java	URL de téléchargement : Java Méthode d'exécution : décompressez le package et exécutez java -jar oss-callback-server-demo.jar 9000 (9000 est le numéro de port, que vous pouvez modifier).
   Python	URL de téléchargement : Python Décompressez le package et exécutez python callback_app_server.py. Ce programme nécessite la dépendance RSA.
   PHP	URL de téléchargement : PHP Pour l'exécution : déployez le script dans un environnement Apache. Vous devrez peut-être adapter l'exemple, car la récupération des en-têtes en PHP peut dépendre de l'environnement.
   .NET	URL de téléchargement : .NET Pour exécuter l'application, décompressez le package et consultez le fichier README.md.
   Node.js	URL de téléchargement : Node.js Pour exécuter l'exemple, décompressez le package et lancez node example.js.
   Ruby	URL de téléchargement : Ruby Pour l'exécution : ruby aliyun_oss_callback_server.rb

Paramètre de rappel

Le tableau suivant décrit les champs du paramètre callback, utilisés pour configurer le contenu et le comportement de la requête de rappel envoyée après le chargement réussi d'un objet vers OSS.

Paramètres système pris en charge par callbackBody

Le champ callbackBody du paramètre callback peut référencer plusieurs paramètres système pour transmettre des informations sur l'objet chargé dans la requête de rappel. Le tableau suivant décrit les paramètres système pris en charge.

Rappel en cas d'échec du chargement

Non. OSS déclenche un rappel uniquement après le chargement réussi d'un objet. Si le chargement échoue, aucun rappel n'est envoyé et un message d'erreur est directement renvoyé au client.

Erreur « Response body is not valid json format »

• Une exception lors du traitement sur le serveur d'application entraîne l'envoi d'un corps de réponse non conforme au format JSON valide, comme illustré dans le code suivant :

  # Send a response to OSS.
  resp_body = '{"Status":"OK"}'
  self.send_response(200)
  self.send_header('Content-Type', 'application/json')
  self.send_header('Content-Length', str(len(resp_body)))
  self.end_headers()
  self.wfile.write(resp_body)

  Solution :

  • Exécutez la commande suivante pour vérifier le contenu.

    curl -d "<Content>" <CallbackServerURL> -v

  • Capturez les paquets pour inspecter le contenu.

    Sous Windows, nous vous recommandons d'utiliser Wireshark pour capturer les paquets. Sous Linux, utilisez la commande tcpdump pour effectuer la capture.

• Le corps de la réponse renvoyé par le serveur d'application à OSS contient un en-tête BOM.

  Cette erreur est fréquente sur les serveurs d'application basés sur PHP. Le SDK PHP renvoie un en-tête BOM, qui ajoute trois octets supplémentaires au début du corps de la réponse reçu par OSS. Cela rend le corps invalide en tant qu'objet JSON. Dans la capture de paquets suivante, les octets ef bb bf représentent l'en-tête BOM.

  Frame 6: 448 bytes on wire (3584 bits), 448 bytes captured (3584 bits)
  Ethernet II, Src: Inventec_5e:4f:5c (00:8c:fa:5e:4f:5c), Dst: Inventec_5e:4b:64 (00:8c:fa:5e:4b:64)
  Internet Protocol Version 4, Src: 10.101.166.30, Dst: 10.101.166.53
  Transmission Control Protocol, Src Port: 8083 (8083), Dst Port: 49607 (49607), Seq: 1, Ack: 518, Len: 382
  Hypertext Transfer Protocol
  Line-based text data: text/html
    \357\273\277{"Status":"Ok"}
  0090  64 20 48 61 74 29 0d 0a  53 65 74 2d 43 6f 6b   d Hat).. Set-Cook
  00a0  69 65 3a 20 50 48 50 53  45 53 53 49 44 3d 66 61   ie: PHPS ESSID=fa
  00b0  74 37 33 6e 74 6c 70 68  30 6e 63 67 38 68 33 30   t73ntlph 0ncg8h30
  00c0  65 6e 75 35 31 34 67 31  3b 20 48 74 74 70 4f 6e   enu514g1 ; HttpOn
  00d0  6c 79 0d 0a 45 78 70 69  72 65 73 3a 20 54 68 75   ly..Expi res: Thu
  00e0  2c 20 31 39 20 4e 6f 76  20 31 39 38 31 20 30 38   , 19 Nov  1981 08
  00f0  3a 35 32 3a 30 30 20 47  4d 54 0d 0a 43 61 63 68   :52:00 G MT..Cach
  0100  65 2d 43 6f 6e 74 72 6f  6c 3a 20 6e 6f 2d 73 74   e-Contro l: no-st
  0110  6f 72 65 2c 20 6e 6f 2d  63 61 63 68 65 2c 20 6d   ore, no- cache, m
  0120  75 73 74 2d 72 65 76 61  6c 69 64 61 74 65 2c 20   ust-reva lidate,
  0130  70 6f 73 74 2d 63 68 65  63 6b 3d 30 2c 20 70 72   post-che ck=0, pr
  0140  65 2d 63 68 65 63 6b 3d  30 0d 0a 50 72 61 67 6d   e-check= 0..Pragm
  0150  61 3a 20 6e 6f 2d 63 61  63 68 65 0d 0a 43 6f 6e   a: no-ca che..Con
  0160  74 65 6e 74 2d 4c 65 6e  67 74 68 3a 20 31 38 0d   tent-Len gth: 18.
  0170  0a 43 6f 6e 6e 65 63 74  69 6f 6e 3a 20 63 6c 6f   .Connect ion: clo
  0180  73 65 0d 0a 43 6f 6e 74  65 6e 74 2d 54 79 70 65   se..Cont ent-Type
  0190  3a 20 74 65 78 74 2f 68  74 6d 6c 3b 20 63 68 61   : text/h tml; cha
  01a0  72 73 65 74 3d 55 54 46  2d 38 0d 0a 0d 0a ef bb   rset=UTF -8.....
  01b0  bf 7b 22 53 74 61 74 75  73 22 3a 22 4f 6b 22 7d   .{"Statu s":"Ok"}

  Solution : supprimez l'en-tête BOM du corps de la réponse que votre serveur d'application renvoie à OSS.