Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NRCS Envelope Fault #17

Open
EntilZha opened this issue Nov 8, 2014 · 15 comments
Open

NRCS Envelope Fault #17

EntilZha opened this issue Nov 8, 2014 · 15 comments

Comments

@EntilZha
Copy link

EntilZha commented Nov 8, 2014

Got around to working more on the NRCS wsdl service I was interested. Ran into another problem, like before open to helping, but some insight/maybe fix would be great. I am using the code from #15

Below is what I wrote additionally to query all stations which are also snotels, so using networkCd of SNTL.

func GetSnotelStations() ([]string, error) {
    request := &getStations{NetworkCds: []string{"SNTL"}, LogicalAnd: true}
    stations, err := service.GetStations(request)
    if err != nil {
        return nil, err
    }
    return stations.Return_, err
}

When I do this, I get the following error:
PANIC: expected element type <getStationsResponse> but have <Fault>

Wireshark shows these request contents, couldn't find a way to copy/paste so they are images
out
500a
500b

Here is the wireshark of my pre-existing ruby code that makes a successful request.
correct

Thanks and let me know how else I can help with info/etc

@c4milo
Copy link
Member

c4milo commented Nov 8, 2014

It seems to be a namespace issue. Go XML package doesn't support namespace prefixes yet but it does set the namespace attribute on each element explicitly instead. That NRCS service doesn't seem to be aware of this and is rejecting what I would consider a valid SOAP request that is at the same time WS-I compliant.

Assuming they are using Java, by default the native Java DOMBuilderFactory is configured to ignore namespaces, thus <getStations xmlns="http://www.wcc.nrcs.usda.gov/ns/awdbWebService"></getStations> is considered an unexpected element. They need to instruct their unmarshaller to be aware of namespaces in elements, like so: http://stackoverflow.com/a/24399323/2807845. But, considering that's a government service, I guess, we will have to work around that issue somehow. Any help is very much appreciated as I'm out of extra cycles right now.

@EntilZha
Copy link
Author

EntilZha commented Nov 8, 2014

If you could give some direction, I could try working something out. I also actually know some of the people that work for the NRCS on this service in particular, although unlikely, might be able to do something on that end.

@c4milo
Copy link
Member

c4milo commented Nov 8, 2014

FWIW, I did improve a little bit error reporting when SOAP faults are received: 8cdcd28

@c4milo
Copy link
Member

c4milo commented Nov 8, 2014

@EntilZha these guys ran somewhat into a similar issue and worked around it: https://bitbucket.org/anacrolix/dms/commits/fbd23ce

@c4milo
Copy link
Member

c4milo commented Nov 8, 2014

Regarding direction, I would start by reading how the Go xml package is currently dealing with namespaces to see if they can be easily defined at the top of the XML document, using prefixes. In other words, I would try to tackling this issue: https://code.google.com/p/go/issues/detail?id=6800

@EntilZha
Copy link
Author

EntilZha commented Nov 8, 2014

So just to test my understanding, the issue is the xmlns attribute on the getStations element? If it were not there, it would work correctly (it is not related to the "tns" in tns:getStations)?

So the "fix" would be figuring out a way to stick this at the top of the xml doc?
<Envelope xmlns:tns="http://...">

@c4milo
Copy link
Member

c4milo commented Nov 8, 2014

So just to test my understanding, the issue is the xmlns attribute on the getStations element?

Yes, it has to be replaced by a namespace prefix in the element instead.

So the "fix" would be figuring out a way to stick this at the top of the xml doc?

Yes, and setting the namespace with the prefix like so <tns:getStations></tns:getStation> instead of the URL repeated in each element of the XML document. The prefix will have to be auto-generated too, making sure it is unique within the document.

@anacrolix
Copy link

I look forward to seeing how you guys deal with this. As far as I'm concerned XML is an unfortunate necessity and poorly supported by the Go standard library. I also found that Go's "size optimizations" regarding " and ' caused problems with some decoders.

@EntilZha
Copy link
Author

Any advice on where I might learn to get an idea of what I will need to do in order to accomplish that? (Reading through the prior link, wondering other resources to in general get knowledge required since I am not super savy on xml/soap prior to this)

@c4milo
Copy link
Member

c4milo commented Jan 17, 2015

Hey @EntilZha, apologies for the very late response. So, in addition to what I previously mentioned regarding how to start tackling this issue, I would also suggest asking in the golang-dev mailing list. By the way, the issue was moved to golang/go#6800.

@EntilZha
Copy link
Author

I ended up on using Scala for this project in part for native support through existing Java libraries (in part from preference) and am too busy to work on this separately. If I end up having time in the future, I will take your advice though. Thanks

@notzippy
Copy link
Contributor

I was able to resolve this issue by using another package : https://github.com/jteeuwen/go-pkg-xmlx , this package transformed the xml into an node struct, which I was then able to parse and reassign the name spaces in accordance to the headers. Then perform a SaveDoc and voila nicely marshelled document

@c4milo
Copy link
Member

c4milo commented Mar 18, 2015

@notzippy, nice! do you think we could use that library in gowsdl?

@notzippy
Copy link
Contributor

Hoping to, I am working through a solution... will let you know what I have in the form of a PR later

@c4milo
Copy link
Member

c4milo commented Mar 18, 2015

ah, great! thank 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

No branches or pull requests

4 participants