Touver le bon MimeType pour son fichier

Lors d’un développement que j’ai eu à faire récemment, je me suis posé la question suivante : Quel est le MIME type du fichier que je suis sur le point d’envoyer en réponse?

Un MIME type (Ou Content-Type, c’est selon) est l’un des mécanismes important lorsqu’il est temps de distribuer le contenu au client. C’est ce qui permet d’identifier le type de contenu que le serveur vous envoie. Pourtant, de mémoire, je ne pourrais qu’en nommer deux ou trois tout au plus.

Si vous n’êtes pas plus capable de moi d’en nommer par cœur, rassurez-vous car il s’agit de quelque chose qui est normalement géré par votre serveur web.

Pour ceux qui sont du genre à lire des RFC, le RFC 2046 est celui qui définit le standard appelé : Multipurpose Internet Mail Extensions (MIME). Il met sur la table tout ce qui est nécessaire afin d’être en mesure de transférer un fichier binaire à travers un courriel qui est transféré uniquement en texte.

Le concept a été initialement prévu pour le courriel. Son utilisation a été étendue à d’autre protocoles incluant HTTP, comme dans le cas qui nous intéresse.

Prenons en exemple une réponse typique d’une requête à http://en.wikipedia.org/wiki/Internet_media_type.

À la ligne trois, l’identifiant Content-Type nous indique à quel type de contenu auquel nous avons face. Dans ce cas-ci, il s’agit d’une simple page HTML utilisant l’encodage UTF-8.

Le Content-Type est composé de trois éléments sous le format suivant : Type / Sous-Type; charset=Encodage. Sachez que l’encodage est optionnel.

La problématique à résoudre

Il est essentiel d’identifier son fichier lorsqu’on l’envoie au client au risque que ce qui est envoyé va être soit ouvert par la mauvaise application ou même simplement affiché comme un flux binaire à l’écran. Ce qui n’est pas vraiment très très utile.

Il existe plusieurs façon d’arriver à sa fin pour l’identification de son Content-Type. Les façons se résument à :

Ce que j’ai préféré faire

Étant un paresseux de nature, j’ai préféré y aller vers une solution sollicitant le moins d’effort possible. Mes recherches m’ont dirigé vers le repository Github nommé csharp-MimeType-Dictionnary.

Mon premier réflexe a été de me demander pourquoi je n’y avait pas pensé avant? L’idée aussi d’extraire le catalogue des MimeTypes d’un site pour les mettre dans un Dictionnaire par la suite!

L’utilisation de cette librairie est comme vous le comprendrez est très simple :

var mime = MimeTypeDictionary["pdf"]

Sans révolutionner le monde du développement web, ce dictionnaire permet rapidement d’avoir accès au MimeType d’un fichier donné sans avoir à le rechercher sur internet. Pour moi, il s’agit d’une économie de temps. Moins que je passe de temps à chercher de l’information plus je suis productif.

Une fois de plus, il faut remercier internet. :)

Advertisements

Design Pattern : Programmation chainée

Un objectif que je me donne en développant du code c’est de limiter le nombre de caractères que je dois taper pour réaliser ce que j’ai à livrer.

Bref, il faut tapper le moins de code possible. Ce qui rejoint parfaitement l’objectif du Spartan Programming et facilite par le fait même la maintenance et facilite la compréhension du code.

Voyons la situation classique d’instanciation d’objet :

Ce que je n’aime pas dans ce code c’est la répétition de la variable smtpServerConfiguration. Tout ce que cela fait, c’est d’ajouter du bruit autour du but actuel du code.

Voilà qu’entre en jeu la désignation chaînée (Fluent Interfaces). Le but de la désignation chaînée est de pouvoir faciliter l’écriture de code en chaînant l’appel des fonctions.

De cette façon :

La conception d’une classe permettant ce genre d’appels est très simple et sa mise en place est liée étroitement à la programmation orientée objet.

Pour ceux d’entre-vous qui font du C#, ce genre d’appels doit vous sembler familier. Il s’agit en effet d’un des deux modes de requête possible avec LINQ. La désignation chaînée a été popularisée avec la venue de LINQ dans le monde .NET où il est possible du code comme celui-ci :

L’utilisation du point virgule dans son code

La programmation est une pratique encore bien jeune. Comme toute chose en quête de maturité, il est normal de remettre en question l’ordre établi.

Un débat a fait rage dans la communauté Javascript vis-à-vis l’utilisation du point virgule dans son code.

L’argument de base de la part du développeur de la librairie Bootstrap est qu’il est possible d’écrire du code avec la plus petite trace possible en tirant profit du Automatic Semicolon Insertion (ASI).

La spécification du langage Javascript mentionne les règles pour qu’un point virgule soit ajouté automatiquement lors de son interprétation.

Par exemple, le code suivant :

return
a + b

Va être interprété de la façon suivante dans la majorité des compilateurs :

return;
a + b;

Or, il s’avère que ce code est incompatible avec la librairie de minification écrite par Douglas Crockford JSMIN. L’idée est que JSMIN ne tenait pas compte du ASI dans la minification du code car il s’agit d’une béquille introduite lors de la conception de JavaScript.

La réponse de Douglas Crockford a été assez brutale

Le point vient du fait qu’il est préférable de séparer les instructions dans le code par des points virgule en dépit de l’espace supplémentaire que cela peut prendre. La même idée est applicable aux expressions telles que les if ou les boucles for,  par exemple. Il faut toujours inclure les accolades pour ces derniers.

Cet épisode de l’histoire de Javascript est un exemple qui illustre comment les optimisations prématurées sont à la source de 97% de tous les maux que nous éprouvons en programmation.

Au final, il faut toujours garder en tête que nous écrivons notre code pour des humains qui auront la tâche de lire à leur tour et non pour des compilateurs qui auront comme tâche de l’interpréter bêtement.