2010-07-20 6 views
1

Le Google Blobstore a récemment ajouté la prise en charge de la diffusion des plages d'octets partiels à partir d'un blob. Lorsque cette méthode est appelée, la réponse est générée avec un code d'état HTTP 206 (Partial Content). Il semble donc que le moteur de l'application suppose qu'il sert toujours une requête Range dans ce cas.Réponses blobstore et HTTP 206 de Google

Cependant, dans mon cas, j'ai regroupé de nombreux fichiers dans une seule entrée blob et je connais la plage d'octets de chacun. Du point de vue du client, ils n'ont accès qu'à une URL représentant un fichier individuel. Dans les coulisses, j'appelle le ByteRange based serve method sur le magasin de blob pour servir le fichier. HTTP 200 est la réponse la plus appropriée dans mon cas, mais le moteur de l'application renvoie toujours 206.

Existe-t-il un moyen de contourner ce problème? (À savoir le retour 200 au lieu de 206?)

Merci, Keyur

Répondre

1

TBH 206 est le code correct, parce que même si le client voir de façon différente, le serveur envoie encore qu'une partie du blob. Techniquement, les codes de réponse sont en partie là pour aider et activer la mise en cache, si elle renvoie 200 OK à une requête de plage alors seulement une entité partielle serait mise en cache par des proxies intérimaires qui supposeraient (à juste titre) qu'elle est l'entité complète. ce qui gâcherait les réponses à d'autres demandes. Doit toujours tenir compte des effets sur le cache, ils font une grande partie du travail sur le Web.

Désolé, je ne sais pas :)

+0

Je comprends les conséquences de la mise en cache et en fait c'est pourquoi je cherchais un 200 ici. Comme je l'ai mentionné, dans mon cas, le client ne fait pas de demande de portée. Dans ce cas, la plage de recherche dans le blob est un détail d'implémentation et non le contrat entre le client et le serveur. – Keyur

+0

ahh excuses, j'ai mal lu :) – nathan