Jump to content

Illegal characters in message header value


This topic is 3041 days old. Please don't post here. Open a new topic instead.

Recommended Posts

  • Newbies

Hi all,

What could be the reason of the following error:

java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: Illegal character(s) in message header value: Basic ...

This occurs when I try to read the list of files from the server or (when I enter the file name manually) when I try to go to the next screen. What is (probably) unusual about the setup is that the FM web server is located on a non-standard port, but the message suggests something is wrong with the login or password. Those are relatively long and contain spaces, but otherwise there's nothing unusual about them.

Kind regards,

Mikhail

Link to comment
Share on other sites

I found the problem - passwords longer than 76 characters are wrapped onto separate lines during the BASE64 encoding process. Taking out that newline character should fix the problem. I'll post a new build here very soon with that fix.

Link to comment
Share on other sites

Please try this version (2.50539) to see if it fixes the problem. I think it will also fix the NullPointerException you were getting when trying to use the automatic bug report.

http://s3-external-1.amazonaws.com/com.prosc.support.uploads/Outbound/360Works%20MirrorSync%202.50539.zip?AWSAccessKeyId=AKIAIDQUCQL7APZLJCDA&Expires=1448632255&Signature=g2qOrHpez4a6z6g%2BTBjvgnOygGU%3D

Link to comment
Share on other sites

  • Newbies

Hi Jesse, thanks for the file. It works differently now, but I got another issue. I'm attaching the screenshot. I've configured FM server to run on port 5080 and specified this on the setup screen. But when I try to get to the next screen, MirrorSync somehow ends up with a completely different response from the server. I've positioned the windows so you can see what it gets and what I get when I access the same address from the browser.

My passwords are not that long (shorter than 76 characters), but they have spaces in them. In the original version this seemed to be the problem, because when I made a provisional login and password without spaces, I was able to progress to the next steps just fine. I didn't complete the setup though because of another issue: this is a multi-file app and the login and password with spaces are shared between multiple files. I only added the short password in the "shell' file that has references to other tables and forgot about other files. As a result when I've set up all the layouts and commanded MS to proceed to the next step (which should produce the sync script), it entered what seemed a neverending loop. (I was able to cancel it.) In the FileMaker log I saw that MirrorSync was denied access to the real files and this probably was the cause of that neverending loop.

To wrap it up:

- The old version seems not to like passwords with spaces in them. The problematic login and password consist of five normal words separated by spaces, e.g. "Alpha Bravo Charlie Delta Echo".

- The old version enters a neverending loop if it cannot access a file. (Not the file it works with, but a related one; I'm not sure which error is returned in this case.)

- The new version somehow gets a wrong response. Maybe it indeed sends a badly formed request and the gateway (IIS, perhaps) responds with error 400 and doesn't even let it pass to FM.

Kind regards,

Mikhail

Forgot to add the screenshot.

mirror-sync-error.png

Link to comment
Share on other sites

  • Newbies

I've tried to use shorter one-word login and password and they worked, so I guess the problem was that they were long and/or contained spaces. I still cannot quite complete the task because the database has lots of tables and, more importantly, perhaps, lots of fields in some of the tables. (A few thousands or so; it was a drag to even put them onto layouts.) So far I had MirrorSync to run for about two hours to get the lists of fields but then gave up. Now I'm going to let it run longer to see if it can chew it all. I'll be back with the findings.

Link to comment
Share on other sites

Hi Mikhail, thanks for the detailed problem report.

I created a new account with username and password both set to 'Alpha Bravo Charlie Delta Echo', and I was able to sync without issue. This is on OS X, not Windows, so maybe that's the difference. Also, this was a single file solution, but the impression that I get from your report is that it would fail even with a single file.

You will hit a limit on the maximum number of fields: It's 998 for a single table. That's because we use the Let() function for assigning variables during the sync, and that has a maximum of 1,000 variables.

Link to comment
Share on other sites

  • Newbies

Hi Jesse,

Yep, I did hit this limit and another one as well: the limit of script steps in the sync script. MirrorSync ended up with 144k steps, while the limits is only about 32k :) It suggested contacting support; what is the procedure here?

From what I see MirrorSync sends a ready-to-evaluate string for each record. Does it limit the number of fields on the server side or it pours them all and let the Evaluate() function to fail later? If so, I might be able to do manual parsing for these few fat tables. Also, do I understand it correctly that this script (with all the underlying details) and the configuration file (the one you can import/export) completely define the sync scenario? That is if I somehow (correctly) produced them myself, I would end up with a fully working sync routine?

Kind regards,

Mikhail

Link to comment
Share on other sites

It would probably be a good idea for us to validate the number of fields and stop the process during configuration, but we don't do that at the moment, which means that FileMaker will fail at runtime when it tries to evaluate more than 1,000 variables.

I really am not sure what to tell you on the idea of parsing everything yourself - if you want to give it a shot, I don't see a concrete reason why it wouldn't work, but you might hit a brick wall somewhere that I am not foreseeing. There is a significant portion of the sync process that happens in a Java web application on the machine where MirrorSync is installed, so the FileMaker script is not the entire sync process, or even the largest part of the process, but it is where the limitation is as far as the number of script steps and variables.

Link to comment
Share on other sites

This topic is 3041 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.