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