perfsonar development work

[Jason Zurawski <>]

Hi All;

I am migrating this to perfSONAR-dev since it brings up an important 
client/server interaction issue that should be dealt with in the entire 
consortium.

The notion of redirection is defined in the HTTP/1.1 (RFC 2616). 
Specifically the section regarding the 3xx errors 
(http://tools.ietf.org/html/rfc2616#section-10.3):

> 10.3 Redirection 3xx
>
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request.  The action
>    required MAY be carried out by the user agent without interaction
>    with the user if and only if the method used in the second request is
>    GET or HEAD. A client SHOULD detect infinite redirection loops, since
>    such loops generate network traffic for each redirection.

perfSONAR requests are typically "POST" (this is how the pSPS client 
operates, someone with knowledge of pSUI should relay what method is 
currently in use).  My reading of this is that automatic redirection is 
an option (e.g. "MAY be carried out"), but only if the request is a 
GET/HEAD.

Further, for the 302 that is being reported from the service:

> 10.3.3 302 Found
>
>    The requested resource resides temporarily under a different URI.
>    Since the redirection might be altered on occasion, the client SHOULD
>    continue to use the Request-URI for future requests.  This response
>    is only cacheable if indicated by a Cache-Control or Expires header
>    field.
>
>    The temporary URI SHOULD be given by the Location field in the
>    response. Unless the request method was HEAD, the entity of the
>    response SHOULD contain a short hypertext note with a hyperlink to
>    the new URI(s).
>
>    If the 302 status code is received in response to a request other
>    than GET or HEAD, the user agent MUST NOT automatically redirect the
>    request unless it can be confirmed by the user, since this might
>    change the conditions under which the request was issued.

My first question is why 302 is being used instead of 301 (permanent 
redirect), the 301 code seems more relevant in this case.  Based on the 
language above, the client is still correct to use the original URI 
since this is a 'temporary' move.

The final paragraph contains the most important info.  The client "MUST 
NOT" automatically redirect without user intervention the request, 
unless a GET or HEAD was sent.

My questions for the audience:

1) What is pSUI doing in terms of of the request type, and is the 
redirection automatic?  If so, this should be examined to be sure the 
spec is being followed.

2) What is the proper way to handle this if automatic redirection is not 
an issue.  This decision could impact client interactions.

3) What is being send to the LS for a service with a redirect in place - 
the old URI or the new?  If the new URI is being sent, the old should 
most likely be purged with a de-registration message.

From the pSPS framework point of view, our non-action on the new 
location is within boundary of the standard, but still leaves the user 
with little information on what happened.  To address this we will be 
looking into either:

 1) An error message to relay the 'location' for 3xx errors
 2) A non-automatic redirection (e.g. the user must confirm they wish 
to use the new location)

Thanks;

-jason

On 1/26/11 8:58 AM, Piotr Pikusa wrote:
> Hi Takatoshi, Jason!
>
> I see that Takatoshi tries to connect with RRD MA developed by GEANT. In
> the new version of RRD MA url has changed from geant2-java-rrd-ma to
> perfsonar-java-rrd-ma, but the old one stayed on server to perform
> re-direct. In psUI redirection works fine.
>
> Regards
> Piotr Pikusa
>
> W dniu 2011-01-26 14:14, Jason Zurawski pisze:
> > Hi Takatoshi;
> >
> > The 302 Error usually indicates that the endpoint is wrong, or that
> > the server is performing some sort of internal re-direct. I printed
> > out the HTTP response headers from this service and see the following:
> >
> > > $VAR1 = bless( {
> > > '_protocol' => 'HTTP/1.1',
> > > '_content' => '',
> > > '_rc' => '302',
> > > '_headers' => bless( {
> > > 'client-date' => 'Sun, 23 Jan 2011 01:03:30 GMT',
> > > 'connection' => 'close',
> > > 'client-response-num' => 1,
> > > 'location' =>
> > > 'http://62.40.123.162:8080/perfsonar-java-rrd-ma/services/MeasurementArchiveService',
> > >
> > > 'date' => 'Wed, 26 Jan 2011 13:04:13 GMT',
> > > 'client-peer' => '62.40.123.162:8080',
> > > 'content-length' => '0',
> > > 'server' => 'Apache-Coyote/1.1'
> > > }, 'HTTP::Headers' ),
> > > '_msg' => 'Moved Temporarily',
> >
> > The 'location field' is the the answer that we need here, that is
> > different than the URL you are sending to below. Try to send something
> > to
> > 'http://62.40.123.162:8080/perfsonar-java-rrd-ma/services/MeasurementArchiveService'
> > instead and see if that succeeds. I did an Echo and it seemed to work.
> >
> > There are two things at play here:
> >
> > 1) The pSPS client doesn't have a lot of sophisticated error handling,
> > so I am not surprised that it reacts this way. I will note this in our
> > issue tracker.
> >
> > 2) Is the MA advertising the address you are using below to the LS? If
> > this address is incorrect, that probably needs to adjusted. That is a
> > question for whomever owns this MA though.
> >
> > Thanks;
> >
> > -jason
> >
> > On 1/26/11 6:08 AM, Takatoshi Ikeda wrote:
> > > Hi.
> > >
> > > In the past, I could get the interface usage data of GEANT
> > > from their RRDMA service by perfSONAR-PS's client (client.pl)
> > > but I can not get now with following error message.
> > >
> > > Is the any information?
> > >
> > >
> > > # /opt/perfsonar_ps/lookup_service/bin/client.pl
> > > http://62.40.123.162:8080/geant2-java-rrd-ma/services/MeasurementArchiveService
> > > SetupDataRequest-IFname-Time.xml
> > > Error sending request to service: 302 Moved Temporarily at
> > > /opt/perfsonar_ps/lookup_service/bin/client.pl line 165
> > >
> > >
> > > [Request message]
> > > <?xml version="1.0" encoding="UTF-8"?>
> > >
> > > <nmwg:message
> > > xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2
> > > .0/"
> > > xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";
> > > xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/";
> > > type="SetupDataRequest" id="SetupDataRequest1">
> > >
> > > <nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";
> > > id="metadata1">
> > > <netutil:subject
> > > xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utiliz
> > > ation/2.0/"
> > > id="s-in-netutil-1">
> > > <nmwgt:interface xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/";>
> > > <nmwgt:hostName>rt1.gen.ch.geant2.net</nmwgt:hostName>
> > > <nmwgt:ifName>so-7/2/0</nmwgt:ifName>
> > > </nmwgt:interface>
> > > </netutil:subject>
> > > <nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:
> > >
> > > eventType>
> > > </nmwg:metadata>
> > >
> > > <nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";
> > > id="metadata1c">
> > > <select:subject xmlns:select="http://ggf.org/ns/nmwg/ops/select/2.0/";
> > > id="subject1c" metadataIdRef="metadata1" />
> > > <select:parameters id="param2c"
> > > xmlns:select="http://ggf.org/ns/nmwg/ops/sel
> > > ect/2.0/">
> > > <nmwg:parameter name="startTime">1293004000</nmwg:parameter>
> > > <nmwg:parameter name="endTime">1293005238</nmwg:parameter>
> > > <nmwg:parameter name="consolidationFunction">AVERAGE</nmwg:parameter>
> > > <nmwg:parameter name="resolution">60</nmwg:parameter>
> > > </select:parameters>
> > > <nmwg:eventType>http://ggf.org/ns/nmwg/ops/select/2.0</nmwg:eventType>
> > > </nmwg:metadata>
> > > <nmwg:data xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";
> > > id="data1" metadataIdRef="metadata1c"/>
> > >
> > > </nmwg:message>
> > >
> > >
> > >
> > > -Takatoshi Ikeda, APAN-JP and JGN2plus