Re: [reSIProcate] Smarter accept header validation in dum?
No objections here, if ain't broke...
~Scott
On February 4, 2005 7:23 am, Scott Godin wrote:
> After thinking about this some more - I think I will just leave the API's
> as is for now.
>
> If a UA supports a particular Content-Encoding or Language for one request,
> there is no reason that it should not support it for other requests. I
> agree it would add flexibility, but it would also make it more difficult to
> configure - ie. you would have to set the supported language / content
> encoding for every request. So unless there is strong opposition to this -
> I won't bother changing the current api's for supported Content-Encoding
> and Content-Language at this time.
>
> Thanks,
>
> Scott
>
> -----Original Message-----
> From: Scott Zuk [mailto:szuk@xxxxxxxxxxxxxxx]
> Sent: Thursday, February 03, 2005 5:31 PM
> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] Smarter accept header validation in dum?
>
> Looks good, thanks.
>
> As for the Content-Encoding and Content-Language validation, I think they
> should be request specific too. It seems a bit odd to me why anyone who
> spoke two languages would for example want to only accept one for Message
> and
> the other for Invite, but it should be perfectly valid. I can't imagine a
> huge need for this functionality, but at the very least changing the
> current
>
> behaviour would keep the api consistent with the new mime type validation.
>
> Regards,
> ~Scott
>
> On February 3, 2005 9:12 am, Scott Godin wrote:
> > Yup - I agree, I missed that problem from your original email - I'll fix
> > it. This whole accept header validation thing is poorly spec'ed out in
> > RFC3261. For reference I've included some attachments from previous
> > discussions.
> >
> > Do you think that Content-Encoding and Content-Language validation should
> > also be per Request Method? I'm thinking they should be request
> > specific.
> >
> > Thanks,
> >
> > Scott
> >
> > -----Original Message-----
> > From: Scott Zuk [mailto:szuk@xxxxxxxxxxxxxxx]
> > Sent: Wednesday, February 02, 2005 4:54 PM
> > To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: Re: [reSIProcate] Smarter accept header validation in dum?
> >
> > I haven't tried out the new code yet, but from the commit diff it looks
> > like
> >
> > the situation I described in my original post will still occur, although
>
> it
>
> > is now solvable.
> >
> > In DialogUsageManager::validateAccept() the for loop that checks the
>
> Accept
>
> > values will sill bail with a 406 the first time it sees an unacceptable
> > value. Of course it had to be this way with the old code, but now that
> > your
> >
> > fix relates mimes to request types I think the loop should only send a
> > 406 if
> > zero Accept header values match. The request should be acceptable if
> > only one mime type matches even if all the rest don't, correct?
> >
> > Thanks,
> > ~Scott
> >
> > On February 2, 2005 1:15 pm, Scott Godin wrote:
> > > I've completed making changes for this and have committed to the teltel
> > > branch. Supported MimeTypes are now Request specific.
> > >
> > > -----Original Message-----
> > > From: Scott Godin
> > > Sent: Friday, January 21, 2005 4:08 PM
> > > To: 'Scott Zuk'; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > > Subject: RE: [reSIProcate] Smarter accept header validation in dum?
> > >
> > > I agree with you, and I like your suggestion. I will add this to my
>
> task
>
> > > list.
> > >
> > > For now - you could just disable Accept validation completely - by
> > > calling profile method:
> > > validateAcceptEnabled() = false;
> > >
> > > -----Original Message-----
> > > From: Scott Zuk [mailto:szuk@xxxxxxxxxxxxxxx]
> > > Sent: Thursday, January 20, 2005 1:23 AM
> > > To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > > Subject: [reSIProcate] Smarter accept header validation in dum?
> > >
> > > Hi,
> > >
> > > I'm trying to get my dum based program to talk with windows messenger,
> > > however
> > > the way the dum handles accept header validation causes all subscribe
> > > requests sent by windows messenger to be rejected.
> > >
> > > WM sends subscribes with an Accept header containing the mime types
> > > "text/xml+msrtc.pidf" "application/xpidf+xml" and
> > > "application/pidf+xml"
> >
> > in
> >
> > > that order. My app is set to reply using only "application/pidf+xml"
> > > so
> >
> > in
> >
> > > theory this should be fine. The problem though is that
> > > DialogUsageManager::validateAccept() sends a 406 failure on the first
> > > unrecognized mime type it sees, even if there is a valid one later in
>
> the
>
> > > list. Is this the intended behaviour?
> > >
> > > I think the dum should take into account the message type when
> > > determining valid accept mime types. Adding a method to Profile that
> > > would allow something like
> > > addSupportedMimeType(Mime("application", "pidf+xml"), SUBSCRIBE) might
>
> be
>
> > > usefull. Are there any current plans to implement something like this
>
> in
>
> > > resiprocate?
> > >
> > > Thanks,
> > > ~Scott
> > > _______________________________________________
> > > resiprocate-devel mailing list
> > > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel