Elément final </feed> manquant

Le problème

Je viens de tomber sur un bug (?) en utilisant WCF Data Services, et je suis pourtant en SP1 de VS2010. Imaginons le code ci-dessous :

using System;
using System.Data.Services;
using System.Data.Services.Common;
using System.Collections.Generic;
using System.Linq;
using System.ServiceModel.Web;
using System.Xml;

namespace Test
{
    [DataServiceKey("ID")]
    public class Modification
    {
        public int ID { get; set; }
        public string Module { get; set; }
        public string CommitID { get; set; }
    }

    public class Historique
    {
        private static List<Modification> _Modifications = new List<Modification>();

        static Historique()
        {
            // Code pour remplir la liste de modifications avec des instances
        }

        public IQueryable<Modification> Modifications
        {
            get { return _Modifications.AsQueryable(); }
        }
    }

    public class HistoriqueCVS : DataService<Historique>
    {
        public static void InitializeService(DataServiceConfiguration config)
        {
            config.SetEntitySetAccessRule("*", EntitySetRights.AllRead);
            config.SetServiceOperationAccessRule("*", ServiceOperationRights.All);
            config.MaxResultsPerCollection = 100;
        }
    }
}

Si j’utilise le code tel quel, le résultat renvoyé par le service OData est du XML mal formé : il manque la toute dernière balise, à savoir la fermeture de la racine </feed> !

Solution temporaire

Visiblement, c’est le MaxResultsPerCollection qui pose problème, car si je remplace son affectation par le code ci-dessous, tout va bien :

config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;
config.SetEntitySetPageSize("*", 100);

D’après différents forums et blogs, il est de toute façon recommandé d’utiliser SetEntitySetPageSize plutôt que MaxResultsPerCollection (et d’ailleurs ils ne peuvent pas être utilisés ensemble, d’après http://stackoverflow.com/questions/5682763/why-cant-we-use-setentitysetpagesize-and-maxresultspercollection-together), mais bon… aucune raison que le XML soit pourri en sortie.

Remarques

Quand on teste sur un navigateur, ça ne pose pas de problème : Firefox comme IE sont en fait extrêmement tolérants (trop…), et le fait que le XML ne soit pas bien formé ne les empêche pas d’afficher le contenu du fil ATOM.

Par contre, dès qu’on utilise un client un peu plus sophistiqué, comme par exemple le plugin PowerPivot Excel, ça plante….

Référence pour le suivi

Si vous avez besoin de suivre la résolution de ce bug, c’est sur http://social.msdn.microsoft.com/Forums/en/adodotnetdataservices/thread/b4f44fdc-ad9a-44fd-941b-4e36e4d5a2db

Réponse Microsoft

La réponse n’a pas tardé, et tenez-vous bien : c’est prévu comme ça ! Oui, WCF Data Services décide d’envoyer exprès un XML mal formé (je n’ai pas dit non valide, mais vraiment mal formé)…

L’explication étant qu’il faut à tout prix faire planter le client pour qu’il ne prenne pas en compte une donnée incomplète. Je ne dois pas avoir tout compris, parce que dans ce cas, pourquoi continuer à envoyer de la donnée, et ne pas simplement envoyer en plus un code HTTP en erreur ?

Et surtout, le but n’est pas du tout atteint, car IE 8 comme Firefox 4 sont justement extrêmement tolérants et affichent tout de même les données, sans montrer de trace d’une erreur…

A suivre sur le forum de Microsoft…