Win a copy of AWS Security this week in the Cloud/Virtualization forum!

Mike London

Bartender
+ Follow
since Jul 12, 2002
Cows and Likes
Cows
Total received
17
In last 30 days
0
Total given
0
Likes
Total received
48
Received in last 30 days
0
Total given
5
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Mike London

Rob Spoor wrote:That's what multipart form-data is for. It uses a boundary between parts (usually a UUID or something similar, but it can technically be anything), and parts can be both files and simple values. Files can be base64 encoded if necessary.

For instance, with content type multipart/form-data; boundary=9fa69c0b-9d14-4e58-92be-599475860bef:
Here, each part starts with --<boundary>, then its headers (one of them needs to be Content-Disposition with value form-data and at least the part name as parameter), then an empty line (like in HTTP headers) and then the value. After the last part comes a line --<boundary>--<\r\n>. Of course you don't want to build that yourself; fortunately, just about any proper HTTP client has support for this.

On the server side, you can receive these parts "low-level" using HttpServletRequest's getPart and/or getParts methods. Frameworks like JAX-RS and Spring MVC have their own abstractions (probably built on top of Part).



Thanks!
1 month ago
I have a client where, currently, she is passing multiple file paths (on the same server) to a micro-service. That micro-service then emails those documents after reading the paths (JavaMail API).

My question is, to make the service more REST-like, how would I best send MULTIPLE binary documents themselves (using Base64 Encoding, etc.) rather than the file paths?

I already understand how I would Base64 the binary documents and can easily do that, but my primary concern is that since all the documents (one or more) would end up in the Request BODY, I need a way to parse them into separate files for emailing.

My idea would be use a UUID between each binary file document on the client side so that on the server side, I would know where one file stops and the next one begins.

Is there a better way to go about this?

Thanks,

-- mike
1 month ago

Tim Moores wrote:Can you post the debug output that should be generated? That often contains valuable hints.



Thanks....I got it working.

The problem was that the com.sun.mail dependency below was 1.5.5. Once i updated it to 1.6.2, mail worked!

Appreciate your reply.

Thanks,

-- mike

   <dependencies>
       <!-- https://mvnrepository.com/artifact/javax.mail/javax.mail-api -->
       <dependency>
           <groupId>javax.mail</groupId>
           <artifactId>javax.mail-api</artifactId>
           <version>1.6.2</version>
       </dependency>

       <dependency>
           <groupId>com.sun.mail</groupId>
           <artifactId>javax.mail</artifactId>
           <version>1.6.2</version>
       </dependency>
       
2 months ago
Hi all,

I have some good JavaMail code that works fine on my Linux server, but when trying to adapt the code to Office 365, I get this error:




Here are my settings:

ENCRYPTED_PORT: 587
SERVER_ADDRESS: smtp.office365.com


Here is the relevant code:




Can anyone see what's wrong here?

Thanks in advance,

- mik
2 months ago

Campbell Ritchie wrote:That readUnsignedByte() method appears to have been introduced at the same time as RandomAccessFile itself (JDK1.0). There were more unsigned methods introduced in some of the java.lang package classes in Java8.



Good info. I get it. Just haven't worked with numerical byte stuff in a long while and mostly forgot about the sign bit.

Thanks to all for the great help and explanations!

-- mike
3 months ago

Mike Simmons wrote:The RandomAccessFile has always been reading the byte array correctly.  The problem is when you interpret this array, you're not getting what you want.

Note that a byte in java is always in the range -128 <= b <= 127.  So 136 becomes 136 - 256 which is -120.  That's the only way to represent this as a Java byte.

Stephan's "offset & 0xFF" is an easy way to reverse this.  You can also use

Byte.toUnsignedInt(b)

which, for b=-120, evaluates to 136.



Thanks Mike!

I created another int header array so I could write the unsigned value back to it and use it later for the offset.

Thanks for your explanation above, also.

-- mike
3 months ago

Stephan van Hulst wrote:You are getting confused by the string representation of the byte.

The point is, it really really shouldn't matter as long as you're not performing a widening conversion. The underlying value is the bit sequence, regardless of whether you interpret it as signed or unsigned numeral. If your ultimate goal is to just display the header, you've already found a solution. If you want to perform other operations, don't worry about the signedness and just treat the byte as what it is: a sequence of bits.



Hello Stephan,

In this case, this byte is the numerical offset into the "DBF" where the first record is.

88 Hex is 136 decimal so I either need to be able to read 88 or 136.

-120 is meaningless as an offset into a file.

What's in the header is 88. I can't get that. The read() gives -120.

Yep, I'm confused by your reply.

Thanks,

-- mike
3 months ago

Mike London wrote:

Carey Brown wrote:Bytes are signed. A byte with the hex value of 88 has the high bit set, meaning it is a negative number. When presented as a decimal integer is -120.




Workaround using RandomAccessFile to get desired result?

Reading with FileInputStream worked OK



Thanks,

-- mike
3 months ago

Carey Brown wrote:Bytes are signed. A byte with the hex value of 88 has the high bit set, meaning it is a negative number. When presented as a decimal integer is -120.



Workaround to get desired result?

Thanks,

-- mike
3 months ago

Mike Simmons wrote:Try using randomAccessFile.readUnsignedByte() for comparison.



I was trying to read in the header using a byte[] buffer and expecting the same bytes as shown in iHex.

The code using the approach you suggested yields the same result (-120):
       

Gotta be a better solution I'm hoping.

Thanks,

-- mike
3 months ago
Hello,

I'm using the RandomAccessFile class since I need to move around the file to different offsets and such.

In the header of the file in question, I have these bytes in Hex:

30140406 74640000 88072606

Byte 8 is 88, yet the buffer from the RandomAccessFile "read", reads -120.

The other values match when converting from Hex to decimal.

Here's the simple code:


The debugger showing the values (in decimal from Hex above) is attached.

So, the value, decimal for 88 hex should be 136 decimal, so why is this -120?

Missing something here.

Thanks for suggestions.

-- mike
3 months ago

Ron McLeod wrote:

Mike London wrote:Changing encoding on client side to Base64 was a workable alternative.


I would have picked ISO 8601 date-only format to form the URL as: /getWeeksFromDate/2020-02-25

It has the side benefit of being human-readable.



Yes, absolutely. No argument.

However, in this case, and implicit in this service was the need to pass a date as common in the third party application.

Thanks again, Ron.

-- mike
4 months ago
Workaround:

Changing encoding on client side to Base64 was a workable alternative.

New code:


Works OK.

As I recall, Tomcat works OK if you POST the URLEncoded date. The problem appears to be in a GET.

Appreciate all the replies.

- mike
4 months ago

Ron McLeod wrote:I think by enabling ALLOW_ENCODED_SLASH, the encoded slashes are not now being interpreted as path delimiters.

I am not familiar with the Spark framework, but with JAX-RS you would use the following syntax to include everything after getWeeksFromDate as parameter data:
    @Path("/getWeeksFromDate/{date : .*}")



I agree that seems to be happening with that Tomcat setting.  If I pass "2" as the date, I get to the method and get the expected error. But, if I pass "2%2F25%2F2020", then I get the 404 error -- meaning there's no such method signature. What you posit must be what's going on.

I need to disable this tomcat setting (was hoping it was the solution) and figure some other way to encode the date. Possibly Base64Encode or something.

Regarding the syntax, yes, SparkJava has totally different syntax. Check out this cool little framework.

This problem definitely seems to be a tomcat issue since running the same code, as I mentioned above, in a standalone SparkJava app (JAR instead of WAR) works fine.

Really strange.

Thanks Ron.

- mike
4 months ago
Wow, thanks.

Well, at least I have a different error.

I put the property setting in catalina.properties

org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true

Now, I'm getting a 404 error.

http://localhost:8080/services/getWeeksFromDate/2%2F25%2F2020

-----------

<html>

<body>
<h2>404 Not found</h2>
</body>

</html>


---

Some progress at least.

-- mike
4 months ago