Skip to content

Conversation

@andrea-manzi
Copy link
Collaborator

the changes did in this commit
2a3a092

makes the client reporting an error now when using the pkgdb at cern, while the server correctly stores the report.

It seems that the server does not report back the "OK" string if we don't pass the --show-error option. Infact the client does not complain if i run the pakiti-client with -d option.

Could be that the problem is server side but if those changes are not essential i would prefer to revert them.

the  changes did in this commit 
CESNET@2a3a092

makes the client reporting an error now when using the pkgdb at cern, while the server correctly stores the report.

It seems that the server does not report  back the "OK" string if we don't pass the --show-error option. Infact the client does not complain if i run the pakiti-client  with -d option.

Could be that the problem is server side but if those changes are not essential i would prefer to revert them.
the output is not really needed in case of successfull upload.
@kouril
Copy link
Member

kouril commented Jul 12, 2018

Hi Andrea,

I'd like to resolve this pending PR but need some clarification from you. I'm not quite clear why the problems were appearing. The OK string you mentioned is the HTTP status code or is expected to part of the application response. With Pakiti server we do the latter.

There's no problem to add the --show-error option back, however I suspect you rather wanted the --include one, which would be very tricky (since we do need to display reports to user sometimes and having HTTP headers there would be a mess).

Daniel

kouril added a commit that referenced this pull request Jul 18, 2018
Based on issue #1 it was found out that different servers use different ways
to pass the return status (an HTTP code vs. an application string in the
HTTP body).  In order to unify the handling, the client relies solely on
HTTP codes now. In particular the client doesn't expect any more a string
returned by the server (see the --expect option).

The basics of the protocol are described in the documentation.

The change also introduces the Perl LWP library to handle HTTP messaging and
doesn't require any external commands for that. Some command line options
become superfluous with the change and removed.
@kouril
Copy link
Member

kouril commented Jul 18, 2018

I've changed the HTTP handling to use the Perl LWP library, which should address your problems. Could you please current client work well for you?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants