[Res] Mock service returning application/x-pointplus for css

Well I looked at the Github sources for SoapUI and it seems that in \soapui\src\main\java\com\eviware\soapui\support\editor\inspectors\attachments\ContentTypeHandler.java the contenttype for css is defined twice:

line 106:

suffixToContentType.put( "css", "text/css" );

line 255:

suffixToContentType.put( "css", "application/x-pointplus" );

I'm not a Java developer, but I guess the second definition overrides the first. If so then that's probably the source of the problem. Am I right?

Thanks,
Christopher

Hi,

You are able to override the Content-Type header in SoapUI by creating "Content-Type" in the header tab and specifying the value for it. Here is a link for the REST request editor:

http://www.soapui.org/REST-Testing/work ... uests.html

mrJames wrote:
You are able to override the Content-Type header in SoapUI by creating "Content-Type" in the header tab and specifying the value for it.

Thank you Marcus. Unfortunately that doesn't help in this case, as the files in question aren't involved in the actual SoapUI mock requests. I have the Swagger UI files under my Docroot folder, and I figured that anything I put there would just get served as static content by Jetty. I have tried serving the Swagger files from a separate server, but then experience different problems, unrelated to SoapUI (POST requests are being issued as OPTIONS requests, for some reason).

Hi,

This has to do with the actual Jetty server and not SoapUI then. This question should be directed to the Jetty forum http://www.eclipse.org/forums/index.php/t/245899/.

mrJames wrote:
This has to do with the actual Jetty server and not SoapUI then.

Thank you Marcus. I joined the Jetty mailing list, posted my question and almost immediately received the following response:

Neither jetty-6 nor even the latest jetty-9.1 has a mimetype of application/x-pointplus in the mimetypes properties file, so this must be something that is being added by the framework or by the application.

Swagger UI is certainly not adding this mimetype (I don't see how it could, anyway). Are you sure SoapUI is not adding it somehow?

Thanks,
Christopher

Hi,

I'm taking a further look at this. Will update you when I get more information.

Hi Christopher

Thanks for pointing out the strange application/x-pointplus. It definitely looks erroneous of defining the css content type twice.
We will remove the application/x-pointplus one in next release.

Once again, thanks for helping us improve SoapUI.

Regards
Joel Jonsson
SmartBear Sweden

SmartBear Support wrote:
We will remove the application/x-pointplus one in next release.

Thanks Joel. I was hoping to demo our API to clients using a SoapUI mock with a Swagger UI frontend in the next few days.

I could, of course, easily run the Swagger UI from a different server, but I have encountered a different issue when I do that - the CORS pre-flight OPTIONS request sent when I do a POST from the Swagger UI is declined, even if I set the correct headers:

"Access-Control-Allow-Origin" "*"
"Access-Control-Allow-Methods" "POST, GET, OPTIONS, PUT, PATCH, DELETE"

I am not sure if that is a Swagger problem or a SoapUI problem. But could you suggest a workaround for my original problem so I could use Swagger in the way I was hoping to? If I built SoapUI myself, but removed the reference to application-x/pointplus, would that work?

Thanks,
Christopher

cortez wrote:

I could, of course, easily run the Swagger UI from a different server, but I have encountered a different issue when I do that - the CORS pre-flight OPTIONS request sent when I do a POST from the Swagger UI is declined, even if I set the correct headers: "Access-Control-Allow-Origin" "*" "Access-Control-Allow-Methods" "POST, GET, OPTIONS, PUT, PATCH, DELETE" I am not sure if that is a Swagger problem or a SoapUI problem.

In fact this also looks like a SoapUI issue. Watching the Swagger UI POST request with Firefox it indeed stalls at the pre-flight OPTIONS method, with a 500 Internal Server error; this is what the SoapUI log displays:

Thu Nov 07 18:06:22 GMT 2013:ERROR:An error occured [Unsupported HTTP Method: OPTIONS], see error log for details

This is from the error log:

Thu Nov 07 18:06:22 GMT 2013:ERROR:com.eviware.soapui.impl.wsdl.mock.DispatchException: Unsupported HTTP Method: OPTIONS
com.eviware.soapui.impl.wsdl.mock.DispatchException: Unsupported HTTP Method: OPTIONS
at com.eviware.soapui.model.support.AbstractMockRunner.dispatchRequest(AbstractMockRunner.java:79)
at com.eviware.soapui.impl.wsdl.mock.WsdlMockRunner.dispatchRequest(WsdlMockRunner.java:377)
at com.eviware.soapui.monitor.JettyMockEngine$ServerHandler.handle(JettyMockEngine.java:715)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

The request does work if I explicitly handle the OPTIONS method in my Groovy script:

if ( mockRequest.method == "OPTIONS" )
{
     return new com.eviware.soapui.impl.wsdl.mock.WsdlMockResult(mockRequest)
}

Is that the right way to handle the request in this context? Should I really have to handle it all? Even when I do that it never actually goes beyond the OPTIONS, so the follow-up POST never gets handled.

Hi

We'll include the css content-type fix in a maintenance build we are doing today. I will let you know when it is done.

Regarding the OPTIONS method that method is not supported in the mocking. I think your workaround is lacking the actual methods in the headers that the OPTIONS method is used for. It's possible that another groovy script workaround can make it work, but it is not supported out of the box from SoapUI at the moment.

Regards
Joel Jonsson
SmartBear Sweden