Discussion :

[Nick56]

Bonjour,

Je viens faire appel à vous car je reste bloqué sur un problème que je n'arrive pas à résoudre.
J'ai un ensemble de services REST développés à partir de l'API Jersey et je rencontre des difficultés pour récupérer la d'un attribut de la requête (attribut multi valué).

Un exemple ci dessous, mais globalement c'est un problème global à toutes les situations du même type.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
@POST
@Path("/alimenter/{objet}")
@Produces( { "text/xml", "*/*" })
public Response addProxyObjects(
		@PathParam("objet") String typeObjet,
		@HeaderParam("idAppli") String idAppli,
		@HeaderParam("pwdAppli") String pwdAppli, 
		@HeaderParam("titles") String titres,
		@HeaderParam("datas") List<String> donnees,
		@DefaultValue("1") @HeaderParam("version") String version, 
		@Context HttpHeaders headers) throws MyException;

La méthode prends ici en paramètre un attribut "donnees" qui doit-être une liste de valeurs passées dans l'entête "datas" de la requête HTTP.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
idAppli=xxx
pwdAppli=xxx
titles=ligne0
datas=ligne1
datas=ligne2
datas=ligne3

En local (Tomcat), je ne rencontre pas de difficultés, l'objet "donnees" contient bien toutes les valeurs passées dans la requête.
Lorsque je déploie sur un serveur d'application "iso prod" (Tomcat + Apache), mon objet "donnees" ne contient plus qu'une valeur composée de toutes les valeurs de la requête séparées par une virgule.

En local, j'ai donc 3 valeurs = "ligne1", "ligne2", "ligne3"
Déployé sur mon serveur cible, 1 seule valeur = "ligne1, ligne2, ligne3"

Le problème survient lorsque je fais appel à mon service en passant par apache (port 80) et disparait lorsque je passe directement par Tomcat (port 8080)

J'utilise la version 1.19 de Jersey (Tomcat 6 + Jdk6)

Une idée , j'ai pu voir quelques sujets traitant du problème mais sans plus de détails m'aidant à le résoudre.

Merci pour votre aide car je m'arrache les cheveux

[tchize_]

Vu que tu passe par des headers, il est possible que le serveur apache fasse du "header merge". De toutes façons, tu es censé accepter que l'on te passer une liste avec virgules, c'est défini explicitement dans le standard au niveau des headers:

Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded.

http://www.w3.org/Protocols/rfc2616/...c4.html#sec4.2

Tu n'es jamais à l'abri d'un proxy entre toi et ton utilisateur qui ferait aussi ce merge d'ailleurs. Donc autant être compatible.

Tu peux regarder du coté du header merge pour ton serveur apache.

j'avoue que je trouve un peu curieux d'utiliser des headers pour des paramètres. En général ça sert à tuner une requête, pas à la construire , genre préciser les encodages qu'on supporte, si il faut cacher, etc

[Nick56]

Merci pour ta réponse. Voyant qu'il y avait quelques bugs déclarés traitant du sujet (corrigés en version 2.x), je pensais qu'il y avais un problème autre.

Effectivement pour les HeaderParam, mais ça date un peu maintenant ! Difficile de revenir en arrière pour le moment.
Mais pour ma culture, les clients ne passant pas par des formulaires (FormParam) et les paramètres d'URLs n'étant pas préconisés (QueryParam) car plus facilement traçables, que me préconiserais-tu ?