Hi John,

I would suggest contacting the Infrastructure team. I believe they're the
only ones who could make that kind of update to an account.

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: [email protected]
E-mail: [email protected]

John Snelson <[email protected]> wrote on 04/17/2011 06:32:34 PM:

> Hi all,
>
> I'd like to handle this - I think I was probably the last person
> working in this area of the code.
>
> My only problem is it's been a while, and I've changed jobs and
> email addresses since the last time I logged in anywhere! Can
> someone get my email address in the system changed to this one, so
> that I can log into JIRA again and take a proper look at resolving this
bug?
>
> Thanks,
>
> John Snelson
>
> On 17 Apr 2011, at 23:03, Eric Swalens (JIRA) wrote:
>
> >
> >     [ https://issues.apache.org/jira/browse/XERCESC-1963?
> page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> >
> > Eric Swalens updated XERCESC-1963:
> > ----------------------------------
> >
> >    Description:
> > It seems that the custom headers set using XMLNetHTTPInfo are
> missing from the actual HTTP request when the CURLNetAccessor is
> used. The SocketNetAccessor does not show this problem.
> >
> > The headerList in the CurlURLInputStream constructor is correctly
> built but from what I understand of the CURL documentation the list
> cannot be freed until the GET request has been made. Currently the
> list feed right after setting the CURLOPT_HTTPHEADER. Delaying the
> call curl_slist_free_all to the destructor solves the issue (patch
attached).
> >
> >  was:
> > It seems that the custom headers set using XMLNetHTTPInfo are
> missing from the actual HTTP request when the CURLNetAccessor is
> used. The SocketNetAccessor does not show this problem.
> >
> > The headerList in the CurlURLInputStream constructor is correctly
> built but from what I understand of the CURL documentation the list
> cannot be freed until the GET request has been made. Currently the
> list feed right after setting the CURLOPT_HTTPHEADER. Delaying the
> call curl_slist_free_all to the destructor solves the issue.
> >
> >    Environment:
> > Xerces-c 3.1.1
> > curl_version: libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3
> > Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1
> >
> >  was:Xerces-c 3.1.1, Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1
> >
> >
> >> Custom HTTP headers missing with CURL NetAccessor
> >> --------------------------------------------------
> >>
> >>                Key: XERCESC-1963
> >>                URL: https://issues.apache.org/jira/browse/XERCESC-1963
> >>            Project: Xerces-C++
> >>         Issue Type: Bug
> >>         Components: Utilities
> >>   Affects Versions: 3.1.1
> >>        Environment: Xerces-c 3.1.1
> >> curl_version: libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3
> >> Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1
> >>           Reporter: Eric Swalens
> >>           Priority: Minor
> >>             Labels: patch
> >>        Attachments: CurlURLInputStream-headers-0.1.patch
> >>
> >>
> >> It seems that the custom headers set using XMLNetHTTPInfo are
> missing from the actual HTTP request when the CURLNetAccessor is
> used. The SocketNetAccessor does not show this problem.
> >> The headerList in the CurlURLInputStream constructor is correctly
> built but from what I understand of the CURL documentation the list
> cannot be freed until the GET request has been made. Currently the
> list feed right after setting the CURLOPT_HTTPHEADER. Delaying the
> call curl_slist_free_all to the destructor solves the issue (patch
attached).
> >
> > --
> > This message is automatically generated by JIRA.
> > For more information on JIRA, see:
http://www.atlassian.com/software/jira
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]

Reply via email to