Kyle- i would like to hear some more on how to represent blob with title or content-type metadata
an example would be axis2 1.4 HexBinary or Base64Binary (BLOBS) accompanied by a String title such as what is represented by this xmime.xsd <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:xmime="http://www.w3.org/2005/05/xmlmime"; targetNamespace="http://www.w3.org/2005/05/xmlmime";> <xs:attribute name="contentType"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:minLength value="3" /> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="expectedContentTypes" type="xs:string" /> <xs:complexType name="base64Binary"> <xs:simpleContent> <xs:extension base="xs:base64Binary"> <xs:attribute ref="xmime:contentType" /> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name="hexBinary"> <xs:simpleContent> <xs:extension base="xs:hexBinary"> <xs:attribute ref="xmime:contentType" /> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:schema> ? Martin Gainty ______________________________________________ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > Date: Wed, 17 Jun 2009 16:45:34 -0600 > From: k...@averageurl.com > To: users@tomcat.apache.org > Subject: Re: Reading POSTed data > > André Warnier wrote: > > Kyle Brantley wrote: > > ... > >> My point, is that it is entirely possible for a browser to POST data > >> to a resource without sending it as multipart/form-data or > >> application/x-www-form-urlencoded. > > Hey! that is cheating. You never mentioned Javascript before. > > ;-) > > > > But true. I wasn't thinking of XMLHttpRequest (which is becoming > > entirely misnamed these days). You /can/ POST any body which strikes > > your fancy. > > > > And you are also right when you mention that assembling a real > > multipart/form-data body may be a p. in the a. > Which is really the only reason that matters as to why I wanted to do > it. I don't want to encode/decode to send to the server, and then do the > same to send to the client. It's a very simple solution. > > > > The real question however is whether you /should/. > Definitely. Granted on every count. > > > > My point (awaiting a more expert opinion still), is that I believe > > that the way the servlet spec is written, you may very well get away > > with it under one servlet container, but not under another. > > Now whether this is a concern in your particular circumstances, is for > > you to know. > > > *nod* Probably will only ever be using tomcat. Unless someone suggests > something else, but I don't think that would be the case... /here/. :) > > > As an aside : in your case, there is also not much stopping you from > > sending your XML body in a way guaranteed to work in all cases. > > You could send it as > > name=........ all your XML, properly URL-encoded .......... > > > > Then it would work also with getParameters(). > > > And you know, I really debated that - but for absolutely no reason at > all, I really wanted to see if I could accomplish it without. That, and > I wasn't sure if I would need to tack on extra encoding - the XML in > question has quite a few element attributes, all with their own > var=whatever pairs. I wasn't positive how getParameter*() would parse > that, and if I would/wouldn't need to add extra encoding. As you laid > out right there, I would need to URL encode the data, and the reality is > I just don't care that much (when presented with another solution that > works with arguably less effort). The client is straight javascript, and > while I'm not the one doing the client ("not my problem"), it would just > be added effort for little to no gain. > > > Unless it is really long of course; I would not recommend this with a > > file. But in that case, there is this : > > > > http://commons.apache.org/fileupload/using.html > > > > which also allows you to handle multipart/form-data containing blobs > > and simple form parameters, together in one POST. > > (Mentioning it because I have often found that what is at the > > beginning a simple case where "all we need to upload, ever, is a > > single blob", turns out in the end to be "..but we'd also like to send > > some additional meta-data describing the blop"). > > > Right. I doubt we'll ever have a need for that, but it would also be an > option. > > I am curious just how the expert opinion turns out, though. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > _________________________________________________________________ Insert movie times and more without leaving Hotmail®. http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd_062009
